Unable to send image on UDP larger than 10K

[zataak]

Hi All,

I am trying to develop a client/server application in which client will send images to the server.

Case 1:
Server is running on one machine that is behind a router and client is running on another machine that is behind some different router. As this communication will be on WAN (public IPs), a port is forwarded on server side router so that server can easily receive incoming UDP datagrams on that port.

UDP's maximum transmission unit (MTU) size is 64KB. It means a UDP socket should be able to transmit anything thing of size less than or equal to 65,536 bytes. When in case of the application i am developing the client is only able to send an image(UDP datagram) of 10-13k. If i try to transfer an image of the size greater than 10Kb, server is unable to receive it and server side UDP socket will be always in (receive) blocking mode.

Case 2:
Server is running on a machine that is behind a router and client is running on a machine that is behind the same router. It means client & server are on the same local area network. Even client and server are sharing the same local area network client is sending the images (UDP datagrams) on server's public IP. In this case server is able to receive any size of UDP datagram upto 64K, which is what i am expecting from my application.

I tried to run my client on different remote PCs but the result is same. Server is not able to receive a UDP datagram of bigger than 10-13Kb. If anyone can help me to deal with this situation, he would be much appreciated.

Link to the code: http://pastebin.com/f644fee71

Thanks and goodluck with your projects. Regards,

Atif

[ahoodin]

Well

#1 Depending on your networking setup, you can have packet crashes.
#2 UDP is unreliable.
#3 You need to ensure that your data is correct..
#4 You need to implement retransmits.
#5 You need to implement error correction.
I looked at your pastebin and....well...You do not check to see how much data was sent by each send. And you are not checking return values. You don't print error messages so you don't know what is going on. In the future you can just put the code on CG and use code tags. The are activated by selecting your code in the CG editor and clicking the CODE button. it puts code tags around the code I think you need better samples to start with. Your problem is that the program is not going far enough to check all these things necessary to debug your problem.

[hoxsiew]

UDP is not the protocol to use for this kind of data transfer. Any router in the path with a different MTU can truncate or drop the packet. Why not use TCP? That's what it is for.

[ahoodin]

UDP is often used for video streaming. It's fast enough. It just requires a little more from the programmer to get there. Such as a protocol over top to make it a little more reliable like Modbus over UDP.

[hoxsiew]

It makes sense for a streaming protocol where it is more desirable for the receiver to lose a packet here and there to preserve the continuity of the stream. Sending a file requires that the fidelity be maintained EXACTLY as sent from the source.

If you insist on doing it via UDP, take a look at the TFTP protocol. It uses (small-ish) UDP packets and maintains structure by sending one packet at a time and then waiting for the receiver to send a packet back acknowledging receipt. Then and only then is the next packet sent. This type of handshaking is not very efficient, but it is very trivial (the T int TFTP) to implement making it attractive for applications where simplicity is needed (like boot rom code in a hardware device).

Still, I don't see why you want to re-invent the wheel and do all the troublesome tasks of reordering packets, requesting resends for dropped packets, etc. when that is exactly what TCP does.

[hoxsiew]

Whoops. I mistook ahoodin for the OP.

[ahoodin]

Slow down a little hosi, take the time to read the posts.

There is a 200 ms packet delay with TCP/IP as deployed on MS Windows making it sort of sluggish.
Hence all the alternate protocols. Have a look at SCTP.