Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a service running on a linux box that receives a fairly constant stream of packets via UDP. The occasional loss or corruption of packets associated with using UDP is fine.

However, the service is under active development, and gets updated fairly often. Every time updates get deployed to it, it has to be restarted and all of the packets that arrive durring the restart are presumably dropped. Also, every now and again a bug makes it into production that takes down the service goes down for a sustained period.

Is there a fairly simple service I can stick between my service and the incoming UDP packets, that will just pass through the packets to the service if it is available or, if the service is down for whatever reason, it'll queue the packets until the service comes back up and then pass them through?

share|improve this question
You could build such an application, I don't know of one already. People usually just built a HA environment with failover for these sorts of situations. – Chris S Dec 13 '11 at 17:28
If the packets are important and cannot be lost without impact to the service, consider adding data integrity checking in the application (to require acknowledgement of datagram receipt) or bringing in the big gun, TCP. – Shane Madden Dec 13 '11 at 17:29
@ShaneMadden's don't use critical data transfers using UDP. That's why you have TCP. Queuing UDP kind of defeats the purpose of UDP; you expect them to be lost and unreliable. – Bart Silverstrim Dec 13 '11 at 18:24
Hmm, interesting. The application generating the packets is just shooting out notifications of events over UDP, and the receiving service is logging them. A lot like the way syslog works. We choose UDP because we didn't want the sending application to really care if the message arrives at its destination or not. It just shoots the message off and carries on. We can certainly tollerate missing events here and there due to lost packets. However, when the receiving service goes offline we basically have a lost period of time where no events get logged, which, while not fatal, is less than ideal. – mikeocool Dec 13 '11 at 19:38

The simple and hacky solution would be to record the UDP stream in pcap format (tcpdump/windump or wireshark could do this) and replay it afterwards - for example using tcpreplay.

It would require quite a bit of logic to include failure detection logic and automatic replays upon service restart, but if your service can handle duplicated messages using the hands-on approach should work well for planned outages.

share|improve this answer

Systemd has a way of preserving sockets between daemon restarts (without losing data). Not sure it also works for UDP sockets, but I would expect so. Don't have more information, my Google fu is letting me down.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.