[p2p-hackers] UDP file transfer link speed identification

[Greg Bildson]

> -----Original Message-----
> From: p2p-hackers-bounces at zgp.org [mailto:p2p-hackers-bounces at zgp.org]On
> Behalf Of David Barrett
>
> > In reality, we decrease the wait time between data packets and
> > actually start making some multiple of wait times zero before a real
> > wait occurs. The zero wait times is just a way of dealing with the
> > fact that our current data message size is small (500 bytes) and
> > fixed at the moment.
>
> Could you restate this in another way?  I didn't quite get what you were
> trying to say; I don't see how wait time is related to message size.
>
> Incidentally, why are your data packets so small?
>
>

Its a little late in the game but let me just follow up with some history
and some answers.

My desire was to make the simplest possible reliable UDP protocol that
performed well.  I started by looking at the trivial file sharing protocol.
This certainly worked but suffered from fairly poor performance given that
there is an ack for each packet.

Packet size wasn't specifically a constraint and I wanted to avoid UDP
fragmentation problems so I chose to fix our initial implementation at 500
bytes of data per packet (with up to 4K allowed).  To get more throughput,
we just send multiple packets with zero delay.  So, a real delay may only
occur after 1, 2, 3, 4, 5, ... 14 packets are sent.

Beyond those basic answers, we added a few very simple ideas from TCP and of
our own making.  Simple as in a 20 packet receipt window, including the
highest contiguous sequence number in acks, suppressing rapid acks to reduce
ack bandwidth, textbook rtt calculations, etc.

Thanks
-greg