UDP Listener Stops with Zero Byte Message

[gdau]

I am currently using this library to create a UDP listener for a GPS tracking system (multiple vehicles as clients connecting to a single instance of my listener). I am using the async method ReceiveAsync() to start the processing loop.

i.e. in my own class that inherits from the UdpServer:

protected override void OnStarted()
        {
            ReceiveAsync();
        }

In my overridden OnReceived I process the incoming bytes in the following way:

protected override void OnReceived(EndPoint endpoint, byte[] buffer, long offset, long size)
        {
            try
            {
// Message processing goes here.
            }
            finally
            {
                ReceiveAsync();
            }
        }

So my OnReceived is responsible for calling ReceiveAsync again so that the listening loop can continue. The issue I have is that, under some conditions, I will receive a zero length datagram (while one of the GPS devices is starting up, it sometimes sends an empty datagram - this is not something I have control over). In this case, the ProcessReceiveFrom method within the library checks for the presence of the zero length message and just returns - without calling my OnReceived handler.

Because my handler is never called, I never get the opportunity to call ReceiveAsync() which means it effectively ends the loop and the listener stops processing any incoming messages. The code within the library ProcessReceiveFrom looks as follows:

if (size == 0)
            {
                 return;
            }

To fix it, I have forked my version and removed that check for zero size (so it always calls my handler) - and then I cater for the potential of a zero size in my own handler. My understanding is that a zero byte message had special meaning in TCP, but in a connectionless environment like UDP, is this still the case? Is there some pattern here I am missing?

Thank you.

[raubert4]

Hi,

I figured out the exactly same situation. I'm using the branch for .net framework. I've also forked my own version where I call TryReceive method when message size == 0.

Are you planning to change it ? Is there maybe another way to handle this case that I've missed ?

Thanks for your help

[gdau]

Hi,

I figured out the exactly same situation. I'm using the branch for .net framework. I've also forked my own version where I call TryReceive method when message size == 0.

Are you planning to change it ? Is there maybe another way to handle this case that I've missed ?

Thanks for your help

I am also using the .NET framework version.

I was hoping to hear back from the author about this and didn't figure out another way. If it makes you feel any better, I made the change I mentioned above and it's been running as a windows service in production for several weeks now without being restarted - processing hundreds of thousands of messages - so there doesn't seem to be any negative side-affects to this change that I can see so far.

Hopefully the author will weigh-in and we can get this change pushed so we can go back to using the nuget package.

[raubert4]

Hi, I figured out the exactly same situation. I'm using the branch for .net framework. I've also forked my own version where I call TryReceive method when message size == 0. Are you planning to change it ? Is there maybe another way to handle this case that I've missed ? Thanks for your help

I am also using the .NET framework version.

I was hoping to hear back from the author about this and didn't figure out another way. If it makes you feel any better, I made the change I mentioned above and it's been running as a windows service in production for several weeks now without being restarted - processing hundreds of thousands of messages - so there doesn't seem to be any negative side-affects to this change that I can see so far.

Hopefully the author will weigh-in and we can get this change pushed so we can go back to using the nuget package.

Can you create a Pull request with your new version ?

[gdau]

Hi, I figured out the exactly same situation. I'm using the branch for .net framework. I've also forked my own version where I call TryReceive method when message size == 0. Are you planning to change it ? Is there maybe another way to handle this case that I've missed ? Thanks for your help

I am also using the .NET framework version. I was hoping to hear back from the author about this and didn't figure out another way. If it makes you feel any better, I made the change I mentioned above and it's been running as a windows service in production for several weeks now without being restarted - processing hundreds of thousands of messages - so there doesn't seem to be any negative side-affects to this change that I can see so far. Hopefully the author will weigh-in and we can get this change pushed so we can go back to using the nuget package.

Can you create a Pull request with your new version ?

I ended up only including the few classes I needed in my own project rather than forking the whole thing - the UDP server only needs 3 or so classes to function - but I have gone ahead and made those same changes via a pull request now.