I notice in a recent packet trace that the advertise library (centralizedadvertise and centralizedadvertise_v2 it seems) uses the same TCP source port for every connection. This is not problematic when a seconds elapse between connection attempts.
In the case of Affix-enabled lookup, we do multiple lookups in a row however: Consider seash that looks up the user's public key first, then looks up the advertised value of each node under that public key, and then further looks up stuff like the Affix stack it should use to contact the node. Each new connection gets delayed, and this causes the whole lookup process to take tens of seconds.
The current logic (inside sockettimeout) does test for source port availability when a new connection is attempted. Now my Mac OS X 10.6.8 box here considers a quintuple to be reusable after the closing four-way handshake is over so none of the obvious "port already in use" Repy exceptions are raised, but the remote side (Linux) doesn't allow me to reconnect until 3-4 seconds have passed.
If we can't correctly detect back-to-back port reuse through the logic in emulcomm, then we can at least shuffle the list of ports to try in sockettimeout to reduce the probability of this event happening. A stateful approach is possible too: Remember which quintuples have been released recently and don't let the user reuse them until an expiration timer has passed.
I'll try the stateless, randomized approach first and report back.
I notice in a recent packet trace that the advertise library (centralizedadvertise and centralizedadvertise_v2 it seems) uses the same TCP source port for every connection. This is not problematic when a seconds elapse between connection attempts.
In the case of Affix-enabled lookup, we do multiple lookups in a row however: Consider
seashthat looks up the user's public key first, then looks up the advertised value of each node under that public key, and then further looks up stuff like the Affix stack it should use to contact the node. Each new connection gets delayed, and this causes the whole lookup process to take tens of seconds.The current logic (inside
sockettimeout) does test for source port availability when a new connection is attempted. Now my Mac OS X 10.6.8 box here considers a quintuple to be reusable after the closing four-way handshake is over so none of the obvious "port already in use" Repy exceptions are raised, but the remote side (Linux) doesn't allow me to reconnect until 3-4 seconds have passed.If we can't correctly detect back-to-back port reuse through the logic in
emulcomm, then we can at least shuffle the list of ports to try insockettimeoutto reduce the probability of this event happening. A stateful approach is possible too: Remember which quintuples have been released recently and don't let the user reuse them until an expiration timer has passed.I'll try the stateless, randomized approach first and report back.