1. Home
  2. Embedded Linux
  3. UDP packets dropping

UDP packets dropping

Hi, I am facing a problem which anyone who has worked on any UDP application might have faced. UDP by itself is unreliable. If packets are lost, no acknowledgements are sent.

I have a UDP application which is receiving packets on a standard port. It receives packets asynchronously. At any time any packet can arrive. The problem is that sometimes a number of packets arrive and our UDP socket buffer ( being of finite size ) is not able to handle them and simply drops the packet. The UDP socket buffer cannot be increased beyond a finite size( dynamically it cannot be increased, it is fixed for an OS) .

So a number of packets simply drop with out any intimation to the receiver/sender.

I need to have checkpoint ( some kind of intimation ) that the packets are being dropped.

I have implemented polling with poll parameter as POLLIN or POLLRDNORM.( I have tried both parameters) Both implementation works that is gives me a poll status implying socket buffer is full.

In my test set up I can control the rate at which packets are generated. When the packets are sent at a very high rate and my socket buffer is not able to handle them, polling status tells me that buffer is full.

when the rate of sending packets is slow, I get an intimation that buffer space is available.

But in some cases ( when the rate of sending packets is slow ), I get a poll status that buffer is full ( which is wrong ). Even though these are corner cases but it made me think.( and caused worry) .

I have following queries..

a) Do we have any mechanism/ way in which we can find that udp socket buffer is full and packets are being dropped. b) Can polling be actually be used. My corner cases made me think that. Is my approach totally wrong. c) If not Polling then what ? d) If polling can be used, which other parameters I can use to avoid these corner case.

e) Is my implementation of polling wrong, Is it possible that I am misunderstanding the polling status to tell whether buffer is full.

if you have some idea about this issue please let me know. If you need some more input from my end let me know. You can mail me at snipped-for-privacy@gmail.com

Reply to
Guddu
Loading thread data ...

You can add some information to UDP packets, like for example number of packets. If a packet is droped, you will know by tracking packet numbers received. But keep in mind the order can be mixed

So, your mechanism does not work :P

I think there are no such things (not sure though)

Can try with packet numbers as I explained

Reply to
VJ

I think your answer is right there in the second sentence. Since UDP is best-effort you can never be sure whether you've lost a packet unless the higher level protocol does some kind of checking. Monitoring the receiving socket state may help but packets could be lost for other reasons so if your upper protocol depends on reliable delivery you have to implement that with sequence numbers, acknowledgements or whatever mechanism is best suited to your app.

This will become very obvious if you move to wireless or some other transport that's less reliable than Ethernet.

Hope that helps, Andrew

Reply to
andrew queisser

Why don't you use TCP ?

-Michael

Reply to
Michael Schnell

The application I am working on is Based on UDP standard..no way we can change that

Reply to
guddu

The OP likes to handle SNMP, which runs on UDP only.

What is not clear to me, he has multi-posted the same question with different titles to several groups. He already has the relevant answers, but it seems that he's not happy with them.

It would have been much easier to respond, if the original question had told that it's SNMP, and if there had been a proper cross-post to relevant groups only.

--

Tauno Voipio
tauno voipio (at) iki fi
Reply to
Tauno Voipio

When designing an application to use UDP the paradigms of UDP (e.g. unreliable transfer) needs to be taken into account. If you need reliable transfer, TCP is designed for that.

If you need to enhance an application that historically was designed to use UDP and now gets an additional channel that needs reliable transfer, IMHO the best way is to use an _additional_ TCP port for that. Why can't you do this ? If _all_ transfer of the application needs to be moved to a reliable channel, of course redesigning it with TCP would be the way to go.

Of course it _is_ easily possible to do a reliable, handshake enabled, protocol on top of UDP, but AFAIK, there is no standard for this and you need to do a completely new propriety implementation (doing a retransfer when the answer times out and rising an error condition when the nth transfer of the same data fails). Of course this likely will be a lot slower than TCP that implements a sophisticated overlapping handshake protocol.

-Michael

Reply to
Michael Schnell

Did you try Capturing the packet (UDP only) with ring/pfpacket socket with memory map (mmap) alongwith polling. this way you will get good performance and also the status of how much packet you received and how much has been dropped.

Also, your kernel muct be comiled with memory mapped packet capture support!

Any time you can check teh status of packet received or dropped by having access to "struct tpacket_stats tpkt_stats_obj" and its members tp_packets (received packets), tp_drops(packets drops).

Enjoy!

rgds, Munish Nayyar emanshu "InnovativeMInd" Cisco Systems, Inc. "Once all village people decided to pray for rain. On the day of prayer all people gathered and only one boy came with an umbrella that's confidence..........."

Reply to
emanshu

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.