This is part of Early Gnutella
Firewall-to-Firewall Transfer
At the higher level, a firewall transfer capable downloader adds a special marking to their MIN_SPEED field in the query. A firewall transfer capable uploader sends back specially marked QueryHits. The downloader uses a push proxy to send a special fwtofw push to the uploader. The uploader and downloader then kick off udp connections on both ends pointing at each other. Then the udp connection algorithm kicks in.
You can take a look at the udp connection messages (and the package) here:
http://limewire.org/fisheye/viewrep/limecvs/core/com/limegroup/gnutella/udpconnect
Each end of the connection starts out sending a Syn message to setup a connectionID, identify itself and open up the firewall in the process. There are dedicated Ack messages in response to every Syn, Data or Fin message. Fin messages are for shutdown. There is also a Keepalive message that shares some of the internal state of Ack messages (windowStart, windowSpace but not the sequenceNumber of what they are Acking).
The superclass of the messages lays out the common fields:
http://limewire.org/fisheye/viewrep/limecvs/core/com/limegroup/gnutella/udpconnect/UDPConnectionMessage.java?r=1.1.6.1
Everything is somewhat intelligently packed into a Gnutella message with parts of the GUID used for data as well. Everything has a sequenceNumber which is physically sent on the wire as 2 bytes but logically and internally mapped to 8 bytes.
The Data messages try to pack 512 bytes of data into a Gnutella message (12 in GUID and 500 in payload). That seems to be enough to avoid super-inefficiency.
The data transfer algorithm is sort of a combination of SFTP with some TCP concepts added on. For better throughput, a window is used to rate control the data messages. The current implementation works with a data window of 20 data messages. The general idea is to try to send data at intervals so as to ensure that you don't overload the other ends receiving window. The other end will ack these data packets with the sequenceNumber, windowStart and windowSpace. The windowStart tells you the lowest sequenceNumber that the other side has not emptied out of its window. Roughly speaking, as the windowSpace starts to approach zero on the other end, you should slow down and stop sending Data. The congestion control is where things get complex.
Note that this algorithm works bidirectionally (so data can flow in both directions). LimeWire uses these connections as regular sockets so they plug into the existing code easily.
