Re: Possible bug in .Net 2.0 udp sockets?

"Al Norman" <al.norman@xxxxxxxxx> wrote in message
news:egreF9v5GHA.4304@xxxxxxxxxxxxxxxxxxxxxxx
Pardon me for butting in, but you should be able to increase the size of
the queue of UDP messages. We do this (in C++) with the following:

int receivesize = RECEIVEQUEUESIZE;
if (0 != setsockopt(mysocket,SOL_SOCKET,SO_RCVBUF,
(char *)&receivesize,sizeof(receivesize)))


where RECEIVEQUEUESIZE is a #define of 1024*1024

You won't miss any UDP packets with a buffer that large!

This is categorically incorrect. There is no way with UDP to guarantee that
you won't lose datagrams.

No one should ever write a program using UDP unless they implement in that
program logic for handling the vagaries of UDP. This includes handling the
following cases:

* The datagram never arrives
* The datagram arrives, but out of order (either before one sent
earlier, or after one sent later)
* The datagram arrives more than once

These are all things that can happen with UDP, and using UDP means one must
anticipate and handle those conditions.

As far as the original question goes, I can't speak for how .NET handles
things, but it is not normally true in Winsock that one's program must be
blocking on a call to receive (in Winsock, recv() or similar) in order to
catch all the UDP datagrams that do make it to your end of the network. It
is true that if you don't process the datagrams fast enough, the buffer can
fill up and some datagrams will be lost. But there's no requirement to be
ready and waiting to receive a datagram the moment it comes in.

I don't know why the MSDN article would say otherwise...whether Winsock will
drop a UDP datagram may be related to the question of whether there's an
outstanding receive on the socket, but it's not a 1-for-1 correlation. A
datagram could get dropped even with an outstanding receive, and even the
absence of an outstanding receive doesn't guarantee the datagram will be
dropped.

Note that all of the above pertains to the default usage. If one sets the
internal Winsock buffers to zero (a common enough technique when using
IOCP), things change and the lack of available buffer space due to the lack
of an outstanding queued IOCP receive could cause a UDP datagram to be
dropped. So perhaps there's something special about .NET's use of Winsock
that causes the statement to be true.

As far as whether it's actually a *problem* to enqueue multiple receives
(that is, to have more than one BeginReceiveFrom outstanding at a time),
assuming other things that have been posted here are correct with respect to
using the Begin/End constructs in .NET's socket implementation, there
shouldn't be a problem doing so. According to those other posts (and note
that I have not personally verified them), the Begin/End constructs use
IOCP, and IOCP will correctly queue the receives.

That said, someone relying on this should definitely confirm for themselves
that IOCP is what's being used. Anything else could possibly involve having
multiple plain-vanilla receives outstanding at the same time, which is NOT
supported by Winsock and could result in indeterminate results, including
something like what the original poster is reporting.

If I had to guess, I'd say that it's much more likely there's a bug in the
original poster's implementation. What that bug might be, I can't say.
Maybe not handling the EndReceiveFrom() method correctly, or using the wrong
data, or something. I don't know. I haven't looked at the full source code
itself...IMHO, if it's worth asking a question about on a newsgroup, it's
worth posting the code to the newsgroup. Providing the code in a linked
..zip download breaks the longevity benefit of using an archivable resource
like a newsgroup in the first place.

Pete


.

Loading