views:

213

answers:

5

There is a data feed server receives feed from various clients by means of UDP,because the clients are pumping data so fast,the receiving buffer is very easily to get full if the server spends time on processing the received data,so

  1. Will it help that if the feed server just multicasts all data it received to the other servers on LAN which the data feed server has a second NIC connects to? Each of the other servers only picks up data it concerns to process and leave the other data to the other servers.
  2. If the incoming data still arrives too fast, is there any strategy to assure not losing any data?

Thanks.

A: 

well you need to write your own "ack" method. Client resends chunk untill gets ack from server that it has been received.

Kamil Klimek
And very soon, you will have a broken version of TCP. Either use TCP or accept UDP limits.
bortzmeyer
+1  A: 

Some strategies to try include

  • Ensure the receiving process does very little in the receive thread, simply read the data and post to an internal queue for processing on another thread - this should reduce the likelyhood of the receive buffer filling up
  • Include a sequence number in your message. If a receiver notices a missed message, it can re request it from the publisher. This re request will be very expensive but make the general case very quick. This assumes the publisher either keeps a reasonable amount of published messages in memory (to allow re requests) or persists them somewhere to cope with replay.
Robert Christie
+1  A: 
  1. If I understand what you are asking then no, because you would be receiving data then sending it out again, effectively doubling the bandwidth you are using, so it probably wouldn't help.

  2. The best strategy to ensure no lost data would be to use TCP over UDP. However, if you have to use UDP, you could write some code that numbers each packet that gets sent (so you can ensure they arrive in order), and add more functionality that allows the server to request a missing packet, e.g.: Sender sends 1, 2, 3, 4, but Receiver recieves only 1, 2, 4, then request 3 again.

mdm
Thanks for you comments.But if the the clients(incoming data) and the others servers are in two separated networks(the data feed server has two NIC, one used to receive incoming feeds,the other one used to forward data),the bandwidth won't be an issue?no?
murphytalk
+1  A: 

UDP can be thought of as standing for 'Unreliable Datagram Protocol'. So that kind of explains your problem immediately: you want reliability, which is a service the underlying protocol does not provide. Probably you want congestion control as well, since lack of network buffers is a source of congestion just as much as lack of bandwidth.

The solution is to use something other than UDP, or to add reliability and congestion control on top of UDP; acknowledgments and rate limiting, essentially.

Possible replacements for UDP include TCP and SCTP. SCTP would be good because it has a datagram mode, so you don't have to convert the protocol to working with streams. See here: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

Andrew McGregor
A: 

If you need reliability with UDP then you have to build your own on top of it. As others have said, you need some method of sending an ACK from one peer to another to tell the other peer that the data has arrived safely. The other peer can then selectively resent datagrams until they have been ACKed.

I have a question open here: http://stackoverflow.com/questions/107668/what-do-you-use-when-you-need-reliable-udp which is collecting various options for adding reliability to UDP based transfers.

Len Holgate