UDP send / recieve issues – potential overflow

[Anonymous]

Hello,

I am developing a client – server application which streams jpeg frames (2 simultaneously) from the server to the client. The images are 10 kB and are sent approximately 15 times per second. They are on separate UDP Sockets and ports.

I have used ThreadSafeStream and StreamSendWrapper to send the objects. All frames are sent and received on the separate threads.

With certain clients, with lower spec. hardware, the frames fail to be received on the client side (no error occurs). This only happens with both streams online and not with one.

I suspect UDP Buffer overflow and have consequently attempted to code the image processing on the server side to reduce the frame size if the FPS drops on the client. This doesn’t help as once this occurs it takes 30 secs for the stream to continue.

I am using not using any serializers or data processors (as give latency which it’s important to reduce) and have set the queue priority to highest on the client side.

I am utterly stuck and would appreciate any advice on how to deal with this issue.

I am using V3.0.

Regards,
Lewis H

• This topic was modified 10 years, 9 months ago by .

[Anonymous]

Hi, I am not aware of the inner details about UDP implementation in NetworkComms but let me suggest you a couple of things. Until NetworkComms offers better support for UDP use it only for sending packets with an amount of bytes lower than the MTU size. The MTU size without counting header bytes is 1500 bytes (chose 1440 to be fine). Your send rate, 15 times per second is ok, but the size (10KB) per packet (using UDP) is not ok. For this to properly work the NetworkComms team should have to implement “Congestion Control” for UDP and other features that emulates TCP like fragmenting big UDP packets into smaller size datagrams and so on. Also remember than when using UDP in current implementation of NetworkComms packets can be lost, out of order and duplicates.

My current advice is that you should try with TCP, and if you are streaming video you can use a codec for compression instead of sending raw images frames (just compressing to jpg is not enough). However if this is not a problem of buffer overflow as you point out, TCP should do the work since 10KB 15times per second is ok in terms of bandwidth for most networks.

[Anonymous]

Heya Lewis,

Yandy’s response is very insightful, he has hit the nail squarely on the head. The UDP implementation currently provided by NetworkComms.Net is RAW UDP only. This works very well for sending small packets that may be lost/duplicated or received multiple times. What you are seeing however is the consequence of when this RAW service breaks down. We are aware of this limitation and it is at the top of our to do list for the next feature release, 3.1. In the mean time you have the following options:

1. Use TCP – although for a streaming application this is not ideal.
2. Break your images into smaller chunks (as suggested by Yandy). i.e. send only a portion of the image in each packet and rebuild complete images on the remote side.

Kind regards,
Marc

[Anonymous]

Yandy and MarcF – thanks for the solid advice – looks like breaking it into smaller chunks is the way to go. The codec option is a good suggestion also, much less network intensive than the current method, it seems.
Looking forward to V3.1!
Cheers,
Lewis H

[Author]

Posts