TUUS, TCP and UDP are transport protocols, meaning they lie in the Transport level of both the OSI Reference Networking Model and TCP/IP Architectural Networking Model. Anyway they don’t really care WHAT they transport.
That being said, in TCP/IP you DON’T have another choice but one of these two when you want to transport higher protocol data.
BitTorrent, LT-Seeding, eDonkey, HTTP/FTP are all application protocols, which means they lie on a higher level than Transport level, so they must rely on one of these two transport protocols, at a minimum, for segmentation, encapsulation, multiplexing and addressing at process level (port numbers).
There is no going around that, period.
Now, TCP uses a negotiation by means of a 3 way handshake, but it only does that for itself (TCP) at transport level, meaning it will establish a TCP connection in order for it to function, irrespective of the needs for a connection of the higher transported protocol.
UDP doesn’t involve any negotiation or handshake; it just provides segmentation, encapsulation, multiplexing and process-level addressing, but doesn’t provide error control or flow control. If the application which sends data over it, needs those features it will need to implement them in an application protocol (at the higher level).
OTOH any higher protocol will need to make negotiations by itself if its specifications require it to, irrespective whether it will use TCP or UDP as a transport vehicle.
That is to say, for instance, that if LTS protocol specifies that there needs be a negotiation between two peers before actual LTS data can begin flowing in any direction, then LTS will need to perform a negotiation of its own, irrespective whether it’s using TCP (and thus a 3-way handshake negotiation took place at Transport level) or it’s using UDP and there was no such negotiation at the lower Transport level.
Each higher level (than Transport) does or doesn’t do its own negotiations (according to its design and specifications) with a total disregard on how the lower level Transport protocol works and whether it uses or not a negotiation process in order to render functional the Transport level (this doesn’t mean that the designer of the application protocol can’t take into account what Transport protocol will use and based on that make a decision if additional error and flow control is needed or redundant).
Therefore, the only thing that is unclear to me and could be clarified by the team is whether, in the implicit setting (TCP+UDP), BitComet will use both protocols simultaneously or it will choose dynamically between the two, and if the latter, what are the conditions (or the algorithm) it follows to choose.
If anyone else has any other questions regarding this, feel free to add them here and bump the thread.
