wouter wrote:
We/I are/am very interested how you will tackle the packet integrity,
packet loss, packet order on UDP connection - server and client-wise.
Please spoil some bandwidth on this and keep it posted here.
Jim can answer for his specific case, but I'll make some general remarks
on UDP protocol / application design.
There is (or should be) no concern about packet integrity. UDP Checksums
cover the data portion of the packet as well as the headers, so you have
high reliability. They are optional; on some hosts you MAY disable them,
but really there is no reason to do so nowadays, we have adequate CPU or
special hardware to calculate checksums.
Note there are a number of apps which will handle misordered packets
only in the special case where two packets are reversed, but handle any
further misordering by dropping the errant packet and using their
data-loss scheme to cover that (rare) case.
Out of order packets and packet loss can generally be handled together
(and should be, since an OOP will initially resemble packet loss).
Generally, the applications for which UDP is suitable fall into one of
the following categories (with corresponding approach to the packet
order problem):
- servers handling many small queries from large number of servers
(e.g.DNS, DHCP)
Packet loss is handled by retries - if a client has not received a
response within some time period - it tries again. If number of retries
gets too high, it gives up. The response to a query contains info to
associate it with the original query - either explicitly, such as a
cookie / seq number, or implicitly, e.g. the request was for DNS info
for a specific domain, the response contains that info.
Out of order packets is pretty much not an issue - requests are
largely independent, frequently single packet anyway.
- streaming media (e.g. VoIP, streamed audio/video, video conf)
The application layer is highly dependent on timely delivery, but
resistant to problems due to packet loss (e.g. codecs which spread an
audio sample over 2-4 packets, such that loss of any one is not
important. They have (typically) very short playback buffers, so cannot
tolerate delay well - e.g. they couldn't afford to re-query for a
missing packet anyway. OOP is usually not an issue because the packet
contains a timestamp which allows it to be slotted into the playback
buffer in the correct order, regardless of delivery order (or discarded
if the playback point has passed).
- streaming data (stock info feeds, commodity trading, betting info, etc.)
Usually have real-time requirements (or very large audiences) which
preclude use of TCP (which they'd really rather have done had it been
possible :-)
Use sequence numbers to detect missing data (often with a playback
buffer scheme to handle simple misorderings).
Often the application is fairly insensitive to lost data (e.g. trade
info can be ignored briefly, and will be fixed when a summary comes in
later (assuming not too many packets get lost) - so it's common to
monitor packet loss, and do nothing more provided the loss remains low
enough (<1% say).
There's a sub-category for "rolling" data, e.g. teletext, where the
data is refreshed periodically, enough that loss can be simply ignored.
- online games (particularly "twitch" games with real-time needs)
Often use a periodic "summary" message to synchronize data,
allowing the app to temporarily ignore lost packets; discovery of a data
synch problem causes triggered updates of the relevant part of the data.
Other than that, much the same as VoIP case.
- polling many clients providing periodic updates to central point
Clients sending keep-alives, where one (or two) can be lost
without the central point deciding a client has gone - so insensitive to
loss or misordering. This remains true even it the "poll" provides more
info, so long as the info is only being summarized, or can be requested
specifically if crucial decisions are to be made (routing protocols,
such as RIP or EIGRP)
Never ignore the possibility of designing in robustness at the
application data layer. This can be anything from the mind-blowingly
simple - (e.g Real Audio back in the very early days, when their UDP
service simply sent every packet twice), to mind-numbingly complex (e.g.
Digital Fountain - uses Forward Error Correction coding to produces a
data stream which can suffer arbitrary packet loss without any data
loss, tuning the acceptable overhead against the observed packet loss
rates).
If you find you are getting too deeply into recovery issues from packet
loss (i.e. a request for retransmit, time outs, etc.) then you should
probably just punt and go with TCP. If that's not an option, then make
sure that any retransmission scheme is sensitive to congestion - i.e.
you can't simply request additional data transmissions over and above
the base transmission without throttling the base transmission, or you
will fall into congestive collapse much too easily.
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.2/349 - Release Date: 26/05/2006
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
