Re: Possible bug in .Net 2.0 udp sockets?

Hi Pete!

When the ID sent by the test application does not match the port number
returned by EndReceiveFrom, which one is actually incorrect? That is, is
the data in the datagram corrupted, resulting in the wrong ID in the
datagram? Or is EndReceiveFrom returning the wrong port?

The incoming data was correct -- the port numbers were wrong. I tested
this a while ago, with more logging. I saw that the client sent some
data, and the exact same data arrived at the server, but with a
different port.

And if
EndReceiveFrom is returning the wrong port, is it just the port that's
wrong, or is the IP address also incorrect?

Hm, I just ran the test on 3 machines (one server, two clients), and the
IP addresses were always correct, while only the ports were wrong. But
in my real application, I think sometimes I got wrong IPs as well --
though I'm not absolutely sure about this.

Another funny thing is that in the test application, the wrong ports
only appear in the beginning (only the first time each listener is
used), while my real application produced wrong ports later on, as well.
I never figured out what is the difference that produces this change of
behaviour.

Do you ever look at the EndPoint that you passed to BeginReceiveFrom? If
not, you should. It would be interesting to know whether it ever gets set
to something other than the default value you gave it before calling
BeginReceiveFrom, and if so whether it looks anything like what
EndReceiveFrom returns, and/or matches the port derived from the received
datagram.

The EndPoint that is passed to BeginReceiveFrom() always stays unchanged
(--> IPAddress.Any, port 0)! Which makes me wonder even more why I have
to pass it as "ref" in the first place ...

IMHO, if the most you're going to be dealing with is hundreds of clients,
you're unlikely to ever see any real performance issues, assuming you're
running on modern x86 hardware.

OK, that's good news -- I have not much experience in this respect.

Well, as you've found, this appears to be unique to .NET 2.0. Perhaps the
article you referenced was written before .NET 2.0 was released?

The article makes no comment on the .Net version to use.
But it was written in February 2006, and had even some references to
"Windows Communication Foundation", so it seems to me that it was
already written with .Net 2.0 in mind.

It all depends on what's going on "under the hood", and it may be that
something changes from 1.1 to 2.0 in which what goes on "under the hood"
makes this problematic for 2.0 when it wasn't for 1.1.

Mhm, this is my best guess as well.

For what it's worth, I posted a question to some other folks who do use IOCP
on a regular basis, and who can problem tell me for sure whether multiple
receives for UDP sockets is valid on IOCP. I don't see any reason it
shouldn't be, but they will be able to confirm that. If so, then I'd say
it's a safe bet that .NET isn't using IOCP in your situation. Whether
that's because it's a UDP socket, or because you have something else going
on with your configuration, or the documentation that claims that the .NET
Sockets use IOCP for the async pattern, I can't say. Any of those might be
possible.

Thanks for forwarding my question!! This could definitely help.

I realize it's all pretty much academic at this point, but if I come across
anything else useful I'll post it back to this thread.

Well, it helped me go on, in any case - academic or not ;)

I won't be able to check this thread in the next 3 weeks, as I am going
on a holiday, but please post anything you find -- I will definitely
check the thread as soon as I'm back. And again: I can't thank you
enough for the efforts you've already made.

Greetings,
Daniel
.

Relevant Pages

  • Re: Delayed UDP messages
    ... like the code is not ready to receive the datagram by the time the reply ... overflow the packet buffer, potentially. ... Paul T. ... You have the port ...
    (microsoft.public.windowsce.app.development)
  • Re: Problem installing port
    ... The port is broken because the pkg-plist is incorrect. ... the port will remain marked broken. ... Paul Schmehl ... overriding an "already registered" package. ...
    (freebsd-questions)
  • Re: Portsnap support on CURRENT
    ... These messages are incorrect ... the "port has" version identified by portversion is older than ... setenv INDEXFILE INDEX-6 ...
    (freebsd-current)
  • Re: Portsnap support on CURRENT
    ... portversion (from the portupgrade port) to list which of my packages are ... These messages are incorrect (i.e., ...
    (freebsd-current)
  • Re: Strange behaviour in pipeline
    ... One quick thought - does your "incorrect" file's name match the filter ... criteria for the port? ... > and that basically just takes an incomming file from a receive location, ... > there are no entries what so ever in the event log about that incorrect ...
    (microsoft.public.biztalk.general)