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
For the same reasons as magic-wormhole/magic-wormhole-mailbox-server#7, I'm thinking of running the client IP address through the MaxMind geolocation DB and recording the country code in the Usage DB. The idea is to figure out (very roughly) where the relay traffic is coming from and use that to decide where to place the relay, to reduce user latency.
The current Transit Relay runs on a Linode box, probably in texas (I just picked the default), but if traffic increases and I want to find a cheaper option, I might move it to a Scaleway box. These are ARM servers with fairly slow CPUs (which we don't really need for the transit relay anyways), and unmetered bandwidth, but they're also based in Europe. Before making that switch, I'd want to get a sense for how much it might slow people down.
I don't think the transit phase of the file-transfer protocol is too latency-sensitive: it's TCP, so it'll fill the pipe as best it can, it might just take an extra few seconds to ramp up the window size to max capacity. But it could add an extra second to a relay-assisted transfer, if the connection-establishment packets take longer to get delivered.
The text was updated successfully, but these errors were encountered:
I'd also be kind of interested in knowing when the two sides used the same externally-visible IP address. That would tell us about network conditions where the two sides are probably on the same LAN, but were unable to make a direct connection for some reason. Basically I'd like to guide the NAT/hole-punching work, but I'm not sure what information would be most useful for that.
For the same reasons as magic-wormhole/magic-wormhole-mailbox-server#7, I'm thinking of running the client IP address through the MaxMind geolocation DB and recording the country code in the Usage DB. The idea is to figure out (very roughly) where the relay traffic is coming from and use that to decide where to place the relay, to reduce user latency.
The current Transit Relay runs on a Linode box, probably in texas (I just picked the default), but if traffic increases and I want to find a cheaper option, I might move it to a Scaleway box. These are ARM servers with fairly slow CPUs (which we don't really need for the transit relay anyways), and unmetered bandwidth, but they're also based in Europe. Before making that switch, I'd want to get a sense for how much it might slow people down.
I don't think the transit phase of the file-transfer protocol is too latency-sensitive: it's TCP, so it'll fill the pipe as best it can, it might just take an extra few seconds to ramp up the window size to max capacity. But it could add an extra second to a relay-assisted transfer, if the connection-establishment packets take longer to get delivered.
The text was updated successfully, but these errors were encountered: