Description
Original discussion: #4398
Good afternoon, dear members of our community!
Specifically, we know for certain that in the current versions of iOS, we have the following memory limitations:
Provider | Limit (MiB) |
---|---|
packet tunnel | 50 |
app proxy | 15 |
filter control | 50 |
filter data | 50 |
DNS proxy | 15 |
app push | 24 |
In our case, Xray is a network process limited to 50MB. It reads geo files and then operates with the read content.
Unfortunately, with the current implementation of geofiles in our core, where all categories are in one large file, we often encounter the inability to even simply start the tunnel on an Apple device.
In particular, with the new geolocation files that we received from our partners, the file sizes have become significantly larger, which means that we cannot load them into memory.
A simple example (Loyalsoldier geosite):
None of the first four categories, if set in the routing rules, will allow the tunnel to start.
This also applies to geo files with CIDR (Loyalsoldier geoip)
Simple example:
@RPRX , considering the memory constraints, perhaps we should explore refactoring the geofile handling code. We could draw inspiration from neighboring teams and implement a system that utilizes multiple smaller files instead of one monolithic file. This approach could effectively resolve the memory issues on Apple devices. What you think about this?