You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the service needs to be restarted manually if the configuration was changed or the host files were refreshed. We should make that more automatic.
DNS server changes
As we re-route the DNS servers currently, we need to restart the service. It might make sense to use to use "virtual" IP addresses again, and then map them on demand instead of overriding routes for the existing servers. This also has the effect of enabling non-DNS packets for those servers again. One disadvantage is that Android might choose to use a non-VPN server under very high latency situations.
Host file changes
Instead of reading all host files into one set, we can read them into multiple sets in threads, and then combine them, and use an atomic reference in the VPN thread. We could also have a queue of changes to be done against the current set, and apply them after poll() returns, but merging in the VPN thread might be too slow.
The text was updated successfully, but these errors were encountered:
Moving to 0.5. It's quite a bit of rework, and I want to get the IPv6 support and user interface tweaks out now, and not mix them with other changes that might potentially break stuff.
Currently the service needs to be restarted manually if the configuration was changed or the host files were refreshed. We should make that more automatic.
DNS server changes
As we re-route the DNS servers currently, we need to restart the service. It might make sense to use to use "virtual" IP addresses again, and then map them on demand instead of overriding routes for the existing servers. This also has the effect of enabling non-DNS packets for those servers again. One disadvantage is that Android might choose to use a non-VPN server under very high latency situations.
Host file changes
Instead of reading all host files into one set, we can read them into multiple sets in threads, and then combine them, and use an atomic reference in the VPN thread. We could also have a queue of changes to be done against the current set, and apply them after poll() returns, but merging in the VPN thread might be too slow.
The text was updated successfully, but these errors were encountered: