1
votes

I have an embedded device which is connected to my PC directly through ethernet.
The device is streaming audio to pc through UDP and it sends 4096 bytes UDP packet.

Given that, the MTU for ethernet is 1500 bytes the packet will be fragmented.

At PC I have a c# program that tries to receive packets and decode it. UDP receiver can receive packets very well when they have under 1500 bytes payload but it cannot receive fragmented packets.

I've monitored incoming packet by Wireshark and I can see that there is not any failure in packets nor discarded.

I don't know the problem is in my code or C# socket is Unable to receive these kinds of packets. in both cases what would be the solution?

1st Attempt: (usinfg Socket)

Socket sokcet = new Socket(SocketType.Dgram, ProtocolType.Udp);
IPEndPoint ep = new IPEndPoint(IPAddress.Any,5222);
sokcet.Bind(ep);
int counter = 0;
while (true)
{
     if(sokcet.Available > 0){
          byte[] bytes = new byte[sokcet.Available];
          int receivedBytes = sokcet.Receive(bytes);

          string print = String.Format("Packet Received : {0},{1}", receivedBytes, counter);
          Console.WriteLine(print);
     }
}

2nd Attempt: (using UDPClient)

IPEndPoint groupEP = new IPEndPoint(IPAddress.Any, listenPort);
UdpClient listener = new UdpClient(listenPort,AddressFamily.InterNetwork);
while (!done)
{        
     byte[] bytes = listener.Receive(ref groupEP);
}

None of them are working for packets larger than 1500 bytes.

Screen shot of wireshark

Update 1: I tested the scenario in Loopback(127.0.0.1) and I can receive 4k UDP message very well.

Update 2: @Evk I tested the scenario from another pc connected to mine over a Switch and also over a router. now I am sure that C# does not have any problem. not sure about OS (win7 ultimate 64x).
My embedded device uses LWIP and there are some reports of a similar situation that happened when users used LWIP for sending large UDP packets. but I'm not sure this is my case.
I even checked UDP packet's Source and Destination address, Checksum and ... and I can't figure out why OS dropping my packets. is there any tools that can analyze network packet to tell if they have any problem?

1
When sending data the receiver must know where the end of message is and read to end. So use one of following 1) Ascii : Terminate data with know character not in message like '\n' 2) Ascii or Binary : Add byte count to beginning of message 3) Ascii or Binary : Used fixed length message.jdweng
the problem is not length variation, the problem is when packet payload is more than 1500 bytes 'sokcet.Receive(bytes);' in the first example and 'listener.Receive(ref groupEP);' in second example do not execute.M.Armoun
"When sending data the receiver must know where the end of message is and read to end" -- this statement from @jdweng is completely irrelevant here, as you are using UDP, a protocol that frames messages for you. You can safely ignore their comment. As for your actual question, it's extremely difficult to offer any useful advice, never mind a good answer, when there's not a good minimal reproducible example that reliably reproduces the problem. Assuming your code works well otherwise, your problem more likely lies in the network configuration than the code itself.Peter Duniho
@jdweng UDP is message oriented protocol (unlike TCP which is stream oriented). "D" in UDP is datagram which can be thought of as message. What you said is true for TCP but not for UDP. When you send something over UDP - you send that as single "block". When you receive something over UDP - you again do that as single block. You can see UdpClient has simple Receive method which returns byte array without you specifying the size.Evk
@jdweng maximum size of UDP fragment is a bit less than 64K bytes. It can be fragmented over multiple IP packets but it will be reassembled on receiving end by network stack. If any fragment of the datagram is lost - entire datagram is lost. You will never receive partial datagram in your socket.Evk

1 Answers

1
votes

I would make certain that the messages are in fact, being delivered to your processes' UDP receive queue. You may see it wireshark, but that is not a guarantee that it did not later get dropped or filtered at the UDP protocol level.

I would open a command window (CMD) and run this in a loop as you send your traffic and run your decoding application (Also, stop other applications that may use UDP as they may interfere with these figures):

> netstat -s -p udp

UDP Statistics for IPv4

  Datagrams Received    = 48775          <======= [This *should* increase]
  No Ports              = 83823          
  Receive Errors        = 16367          <====== [ WATCH THIS]
  Datagrams Sent        = 130194

If you notice receive errors going up while your application sits there and does not seem to processing...then there is chance that the > 1500 byte packets are getting dropped by UDP for some reason. You may need to either increase your application's socket receive buffers or look for windows UDP network configuration options that would cause > MTU packets to be dropped on receive..