Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / Security / November 2006

Tip: Looking for answers? Try searching our database.

UDP packets dropping

Thread view: 
Vishal - 10 Nov 2006 12:59 GMT
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 vishal21@gmail.com
Mike Amling - 12 Nov 2006 18:03 GMT
> a) Do we have any mechanism/ way in which we can find that udp socket
> buffer is full and packets are being dropped.
[quoted text clipped - 11 lines]
> If you need some more input from my end let me know.
> You can mail me at vishal21@gmail.com

  Nothing you do at the receiving end only will reliably tell you
whether a UDP packet has been lost, since intermediate Internet routers
may silently discard packets. You need some cooperation from the
senders. If you need reliable transport, you need to perform the same
functions that TCP does, e.g. ACK, timeout & resend, or something that
gets you the same result.

--Mike Amling
Guddu - 13 Nov 2006 05:56 GMT
>    Nothing you do at the receiving end only will reliably tell you
> whether a UDP packet has been lost, since intermediate Internet routers
[quoted text clipped - 4 lines]
>
> --Mike Amling

Hi Mike,
Thanks for this suggestion.
I am have started thinking in this direction.

Regards,
Guddu


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.