[bittorrent] New P2P protocols

larytet.8708132 at bloglines.com larytet.8708132 at bloglines.com
Sat Mar 26 13:48:28 EST 2005


> if your data
> is stored on media providing random access you do not need
retransmission
> windows, for example.

You dont if you use something like
Linux sendfile which sends direct
from media, or other OS equivalents. The
kernel can do this optimisation
for you

This is not portable. We have
to consider TCP layer as it is with inherit data copying. Good TCP implementation
hides underlying levels from the application. Another problem is tunneling
HTTP and FTP. We quickly will enter proprietary TCP/IP stacks.

> time of
establishing of connection can be reduced
> if we remove TCP handshake.

Your application has a handshake too. Probably much larger.

Any application
i saw used handshake on the application layer besides and above one on TCP
layer - and in my opinion this is rigth thing to do from design point of view.
 Let's keep only one handshake (...and avoid calculating of CRC for TCP frames)


> TCP performs poor on high latency connections
> with burst packet losses
(think link between dial up in small town in India
> and cable modem in the
US).

So do most other protocols.
Some UDP based implemenations tend to
be extremely aggressive when send data and can actually increase TX rate when
there is packet loss. For example, my DataTransferNaive ignores any packet
loss until the whole block (4M in Rodi network) is delivered. If RX does not
see any data for T1 it sends retransmission request containing list of up
to 32 chunks (chunk is 1024 bytes). TX streams all of them and so on. In my
tests this implementation tends to behave pretty well even in conditions of
20% (!) uniformly distributed packet loss.



More information about the BitTorrent mailing list