Matthew Toseland wrote: > That's another interesting point: port rewriting. Right now we don't > take any steps to identify our external port number, apart from using it > as well as our real port number if we hear it from successful connectees.
STUNT uses the following trick, based on the fact that most NATs increase the external port number by 0, 1 or 2 for successive mappings with the same internal address and port number: * Contact first STUNT server, learn external port p1 * Contact second STUNT server, learn external port p2 * Predicted port for next connection = p2 + (p2 - p1) * Peers exchange their predicted ports out of band, then try to connect This might also work with STUN - I'm not sure whether UDP mappings are allocated in the same way but I don't see why they wouldn't be. However, the predicted port doesn't stay fresh for very long unless p1 = p2 (full cone), so it might not be very useful unless the peers have a low-latency channel to exchange predicted ports (eg a mutual friend's node). Cheers, Michael
