[Gllug] [OT] Lost packets

[James Hawtin]

On Fri, Jul 03, 2009 at 12:24:14AM +0100, Martin A. Brooks wrote:
> On 02/07/2009 14:14, James Courtier-Dutton wrote:
> > Hi,
> >
> > If I have a UDP packet one side of the network, and I want to send it
> > to the other side of the network. What is the best way to ensure the
> > information contained in the packet gets through within 1 second
> > without being lost.
> >    
> 
> Don't use UDP.
> 

UDP does have some advantages over tcp, however you are resposible for
sequencing information, a previous post gave a simple algorithm for this. 
Some things to consider.

1. UDP is great for "NOW" information and can scale to many more clients
   than TCP, it is how most stock prices are transmitted. TCP builds up a
   back log there is connection interuption and the algorithm trottles
   back. UDP can be used to throw mud at the wall very fast and hope some of
   it sticks.  

2. UDP packets can be larger than your MTU, this is bad as the packet is
   split then rejoined at the destination, if one of the sections is missing
   you lose the whole packet.

3. Your network infrastructure has a packet size MTU, consider jumbos if you
   can control the setup, Stuff your packet with as much information as
   possible, don't send two when one will work. have a look how tcp works,
   it uses a system called windowing. Interactively it is very slow to wait
   for an acknologement before sending the next byte of information. So if
   you get new data, put it in a packet and pad it out with old information
   that has not been acknologed. However if you find you are re-inventing
   TCP, use TCP.

4. UDP is stateless, this can cause lots of problems providing a return path
   for replies through firewalls. 

5. My favouret thing about UDP, its stateless, this has a big advantage,
   want to be a server you open a socket, bind it to a port, and read the
   FD, with TCP you have to accept the connection this means you need one FD
   per connection, and in the old days 256 was very easy to reach, mangement
   of this limits can be important for TCP, even though the default is
   normally 1024 these days. Being a client on UDP you just open a socket
   and get on with it. 

6. This shows a big problem with UDP, how do you know who sent you want,
   tcp you can "trust" it. UDP its your problem to try to verify who sent
   what and to who. Aways check the packet headers for orginating IP/Socket
   information, put a checksum in your packet to check for
   corruption/modification, magics/versions can also be very helpful. 

If you really "Need" something there in a second, UDP, and TCP make no
difference, make sure there is nothing that could affect the machines, to
increase there latency, and you network equipement has appropiate bandwidth
and capacity to make sure the data arrives, if you have managed switches and
are redundant make sure everything else on the network is lower priority to
make sure it gets there. If its really important, sent it several times!

James
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug