No more asynchronous reception after UdpClient "inactivity"

[Greg]

Hi,

I'm having an issue with the UdpClient class. I use it to receive
asynchronously some data but if no data is received for a delay
(typically some minutes), no data can be received after that (even
though they appear in Wireshark on the good endpoint).

My code is pretty simple :
----
while (true)
{
ar = BeginReceive(callback);
ar.AsyncWaitHandle.WaitOne();
data = EndReceive();
Console.WriteLine(data);
}

void callback()
{
// Nothing to do here, we use the AsyncResult returned by
BeginReceive()
}
----

When I call EndReceive() in the callback, the same behaviour happens.

Does anybody have a clue ? I must be doing something wrong...

Regards,

 

[Peter Duniho]

Hi,

I'm having an issue with the UdpClient class. I use it to receive
asynchronously some data but if no data is received for a delay
(typically some minutes), no data can be received after that (even
though they appear in Wireshark on the good endpoint).

Do I understand this to mean that the datagrams _don't_ appear in
Wireshark on the bad endpoint?

If so, you have a network configuration problem. Most likely culprit I
can think of is that you're going through a proxy or NAT router, and the
entry in the forwarding table has been discarded after some time limit.

But knowing exactly what's wrong will require more investigation on your
part, and consulting in a different forum. It doesn't sound like you've
got a .NET or C# issue here.

Pete

 

[Greg]

Do I understand this to mean that the datagrams _don't_ appear in  
Wireshark on the bad endpoint?

If so, you have a network configuration problem.  Most likely culprit I 
can think of is that you're going through a proxy or NAT router, and the  
entry in the forwarding table has been discarded after some time limit.

But knowing exactly what's wrong will require more investigation on your  
part, and consulting in a different forum.  It doesn't sound like you've  
got a .NET or C# issue here.

Pete

Mhhhh, let's reply to the newsgroup, that work better! (Sorry for
the private mail pete)

I was meaning the packet DO appear in Wireshark and its destination
address is correct (the IP and the port match my
UdpClient.Client.LocalEndpoint). The socket is still openned and owned
by my process (shown in the output of "netstat -ano").

I have also noticed the problem happens also with synchronous
operation !

Here is a "Sandbox" class you can play with (comment/uncomment
synchronous/asynchronous blocks):
-------------
class SandBox
{
public void Play()
{
UdpClient s = new UdpClient();
IPEndPoint ep = new IPEndPoint(IPAddress.Any, 0);
byte[] data;

s.Connect("10.226.10.99", 40006);

AsyncCallback cb = new AsyncCallback(_rxDataReady);
IAsyncResult ar;
while (true)
{
// Asynchronous reception test
//ar = s.BeginReceive(cb, null);
//ar.AsyncWaitHandle.WaitOne();
//data = s.EndReceive(ar, ref ep);

// Synchronous reception test
data = s.Receive(ref ep);

Console.WriteLine(BitConverter.ToString(data));
}
}

void _rxDataReady(IAsyncResult ar)
{
// Nothing to do here
}
}
--------------

I insist on the following point : data can be received forever if
there is no "pause" in the packet flow, when no packet is received for
a while, no more packet can be received anymore...

I can't see any difference in the IP header in Wireshark between the
packets before and after the "no packet delay".

This is very odd!

 

[Peter Duniho]

Hi,

I'm having an issue with the UdpClient class. I use it to receive
asynchronously some data but if no data is received for a delay
(typically some minutes), no data can be received after that (even
though they appear in Wireshark on the good endpoint).

Do I understand this to mean that the datagrams _don't_ appear in  
Wireshark on the bad endpoint?

[...]

Mhhhh, let's reply to the newsgroup, that work better! (Sorry for
the private mail pete)

I was meaning the packet DO appear in Wireshark and its destination
address is correct (the IP and the port match my
UdpClient.Client.LocalEndpoint).

It was clear from your original post that Wireshark shows the datagram.
But in your original post you wrote "on the good endpoint", which I take
to mean the endpoint that is _sending_ the data. The endpoint where the
data fails to be received would be "the bad endpoint". Have you checked
on "the bad endpoint" with Wireshark to see if the datagrams are present
there?

The socket is still openned and owned
by my process (shown in the output of "netstat -ano").

I have also noticed the problem happens also with synchronous
operation !

I would have been very surprised if synchronous or asynchronous i/o made a
difference in this particular problem.

Here is a "Sandbox" class you can play with (comment/uncomment
synchronous/asynchronous blocks): [...]

That was not a concise-but-complete code example, and so may not be as
helpful in diagnosing your problem as you would like. Note also that, as
I've already pointed out, there's a very good chance this has nothing at
all to do with C# or .NET. Your ability to get useful advice here will be
limited, even if you are willing and able to provide a
concise-but-complete code example.

The one thing in your code example I do note is that you are calling
UdpClient.Connect(). When you do that, any datagrams _sent_ to you from a
different address will be discarded, preventing you from receiving them.
You're not specific about the exact network configuration here, but if for
some reason the sender's address changes (IP or port), that would explain
why you stop receiving from the sender.

So, one thing you might try is removing the call to UdpClient.Connect().

Otherwise, as I said before, the problem you describe does not sound at
all like something that relates to C# or .NET. There are much better
forums for asking for help with dealing with network configuration
problems.

Pete

 

[Greg]

Hi,
I'm having an issue with the UdpClient class. I use it to receive
asynchronously some data but if no data is received for a delay
(typically some minutes), no data can be received after that (even
though they appear in Wireshark on the good endpoint).
Do I understand this to mean that the datagrams _don't_ appear in  
Wireshark on the bad endpoint?
[...]

Mhhhh, let's reply to the newsgroup, that work better! (Sorry for
the private mail pete)

I was meaning the packet DO appear in Wireshark and its destination
address is correct (the IP and the port match my
UdpClient.Client.LocalEndpoint).

It was clear from your original post that Wireshark shows the datagram.  
But in your original post you wrote "on the good endpoint", which I take  
to mean the endpoint that is _sending_ the data.  The endpoint where the  
data fails to be received would be "the bad endpoint".  Have you checked  
on "the bad endpoint" with Wireshark to see if the datagrams are present  
there?

The socket is still openned and owned
by my process (shown in the output of "netstat -ano").

I have also noticed the problem happens also with synchronous
operation !

I would have been very surprised if synchronous or asynchronous i/o made a  
difference in this particular problem.

Here is a "Sandbox" class you can play with (comment/uncomment
synchronous/asynchronous blocks): [...]

That was not a concise-but-complete code example, and so may not be as  
helpful in diagnosing your problem as you would like.  Note also that, as  
I've already pointed out, there's a very good chance this has nothing at  
all to do with C# or .NET.  Your ability to get useful advice here willbe  
limited, even if you are willing and able to provide a  
concise-but-complete code example.

The one thing in your code example I do note is that you are calling  
UdpClient.Connect().  When you do that, any datagrams _sent_ to you from a  
different address will be discarded, preventing you from receiving them.  
You're not specific about the exact network configuration here, but if for  
some reason the sender's address changes (IP or port), that would explain 
why you stop receiving from the sender.

So, one thing you might try is removing the call to UdpClient.Connect().

Otherwise, as I said before, the problem you describe does not sound at  
all like something that relates to C# or .NET.  There are much better  
forums for asking for help with dealing with network configuration  
problems.

Pete- Masquer le texte des messages précédents -

- Afficher le texte des messages précédents -

There is no "bad" endpoint, the packet's sender is always sending to
the same iport [destination, our socket] and from the same iport
[source, which is the one the socket is Connect()ed to]. This can be
seen in Wireshark.

The Sandbox class I posted here really is the one I run my tests with!
I can't make it more complete but telling you the console program's
Main function is calling new Sandbox().Play();

Now the source of the problem : Windows'Firewall behaves a bit like a
NAT router, it allows udp packets while there is activity, when there
is no activity within a delay, it blocks them.
This really is an ugly way to deal with security...

By the way you were right, this has nothing to do with .Net, I was not
very confident in my asynchronous reception and I started this thread
here for this reason, and I wrote unclearly which didn't help...

Thank you very much for your support Pete!