Re: Possible bug in .Net 2.0 udp sockets?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Peter!

Thanks for your comments!

1) One very big problem is that you are making the assumption that the ...

You are of course right, and in my real application, I do not make the
assumption that the port which the client sees is the same as the port
that the server sees. But my real application showed the behaviour that
some clients received the WRONG data, which lead me to the assumption
that something with the endpoints went wrong. Thats why I made this
artificial testprogram that I posted here, which does compare the ports.
Of course this testprogram can only work within the same network -- and
the interesting thing is, the error occurs even when both client and
server run ON THE SAME MACHINE, using the loopback device. Under these
circumstances, the ports seen by client and server should indeed be the
same.

Why it should work some times and not other times I don't know. That would
depend on the exact behavior of the router or proxy you're going through.

As I said above, there is no router or proxy inbetween -- it's just the
loopback device you need to reproduce the error.

Why you should never see a problem under .NET 1.1, I also don't know. Are
you sure that you are comparing apples to apples? That is, when you test
under .NET 1.1, are you testing under the exact same configuration as when
testing under .NET 2.0?

Yes, the program uses the same code and runs under the exact same
circumstances -- with the known result that .Net 1.1 works fine and .Net
2.0 produces the error. And, yes, I have installed both runtimes.

That statement implies an understanding that the sender can't know the
actual address that the receiver sees, and yet the code you've implemented
assumes that it can.

I think that should be clear by now: the program I posted is an
artificial one, written with the only purpose to test if .Net's sockets
get the correct endpoints under simple circumstances.

2) An issue that I see as a deficiency in the .NET documentation is that you
pass an EndPoint both to BeginReceiveFrom and EndReceiveFrom. It's not at
all clear to me from the documentation how these two parameters are supposed
to interact, or even why the BeginReceiveFrom method even takes that
parameter. I can't say that I see anything wrong with your methodology, but
at the same time I don't see anything in your code that makes me feel
comfortable that the SocketState.remoteEndPoint is ever set correctly (the
code you posted never actually uses the value, so that's not necessary a
problem here, but it could be in other code that borrows from this code).

Yeah, I perfectly agree with you in this point. To be honest, I never
quite understood why it is necessary to give an EndPoint as "ref" to
both BeginReceiveFrom() AND EndReceiveFrom() -- it's unclear to me
either how those two interact.

3) As a minor stylistic point, I'll suggest that you not use the "as"
operator to cast objects that you know in advance should always be castable.
If you *do* use the "as" operator, you should always check for a null value
after the cast. If you don't check for null, you'll just get an exception
anyway, but it won't be the most direct, useful exception you could have
gotten (as compared to the invalid type exception you'd get casting
normally). I prefer to only use the "as" operator when getting a null
result is a normal possibility for which I'm prepared.

You are of course perfectly right. I omitted the error checking in the
code only to not distract too much from my real problem -- in my main
application, I do of course check for a null value after the cast.

4) Finally, there is still the question of the validity of calling
BeginReceiveFrom multiple times on the same socket before handling an
EndReceiveFrom. If none of the above helps the issue you're seeing, I'd
suggest reducing your "numListeners" to one and seeing if that makes the
problem go away. If it does, that would strongly suggest to me that
multiple outstanding BeginReceiveFrom's on a UDP socket are not supported,
even though this would normally be okay using IOCP with regular Winsock. I
know so little about the underlying workings of .NET sockets, I can't really
offer any advice on why this would or would not be. But results count. :)

Exactly, and the problem really does only occur when there is more than
one listener. As my server application uses the architecture proposed by
another posting anyway (adding the data to a queue which is then
processed in another thread, leaving the socket in a listening state for
as long as possible), I will change it to use only one listener. Using
the workloads I am able to reproduce artificially, I does not seem to
reduce the amount of received packets -- I just don't know if it stays
this way when hundreds of clients are connected; but I suppose it won't
be a problem. As I already said, as this way of handling the data was
proposed by an msdn article, I thought it was a common way of doing so,
and that's why I was quite astonished that the problem with the wrong
endpoints had not attracted someone else's attention before mine.

Hope that helps.

Yeah, that helped a lot! Thanks again for your tipps and comments!
Have a nice day,

Greetings,
Daniel
.

Relevant Pages

  • Re: Winsock / Sockets programming
    ... At the client side receive message from the server only, ... socket on one port. ... And connect everybody to that socket like a big ...
    (microsoft.public.vc.mfc)
  • Re: Winsock / Sockets programming
    ... At the client side receive message from the server only, ... A target of a network connection is a <ip-address, socket#> pair. ... outside the walls of your environment, you should apply to IANA for a Registered Port ... the client has to know the IP address of each potential server. ...
    (microsoft.public.vc.mfc)
  • Re: VB.NET Socket - Multiple clients to server
    ... Private MySocket As Socket ... Dim ipHostInfo As IPHostEntry = Dns.GetHostByName) ... 'Looping periodically on MyTcpListener to see if any client try to ... And I wouldn't have to care anymore with port number? ...
    (microsoft.public.dotnet.general)
  • Re: VB.NET Socket - Multiple clients to server
    ... Private MySocket As Socket ... Dim ipHostInfo As IPHostEntry = Dns.GetHostByName) ... 'Looping periodically on MyTcpListener to see if any client try to ... And I wouldn't have to care anymore with port number? ...
    (microsoft.public.dotnet.languages.vb)
  • Bi-directional SOAP messaging possible?
    ... Is it possible to send and receive messages across the same endpoints, ... Client opens a tcp connection to a server on the ... For this to work across the firewall, it would require something like this: ... It seems to me that there is no way to control the port chosen by the ...
    (microsoft.public.dotnet.framework.webservices.enhancements)