1

I'm testing file transfer speeds between two Red Hat servers that are connected to the same switch within the data center and I decided to use netcat to eliminate protocol overhead as much as possible.

Testing in TCP mode went well and I was wondering how UDP might fare.

On my receiving (client) end, I ran this:

nc -u -l 11225 -v > myfile.out

And then on the sending (server) end I ran the following:

cat myfile.out | nc -u myserver.foo.zzz.com 11225 -v

The file I'm testing with is 38 GB but the transfer seems to stop at around 15 GB (one time at 14.9, another at 15.6).

I've tested by adding a "-w 5000" just in case it's timing out but no joy. Adding the -v doesn't show anything except acknowledging that the connection occurred. No errors.

So - any suggestions as to why would the transfer cease?

Mark Bowytz
  • 113
  • 7
  • UDP is not well suited to transfer files where you need reliability. Ditching TCP for UDP is not a good thing to do. The speed increase will not be that big, and UDP have the obvious downside of not guaranteeing anything. – ThoriumBR Aug 22 '14 at 15:12
  • I agree 100% @ThoriumBR! This is completely for my own testing purposes and personal knowledge. – Mark Bowytz Aug 22 '14 at 15:15

1 Answers1

4

What you are seeing is not a time out. What you are seeing is the result of using the wrong protocol for the purpose.

TCP will perform flow control, which means it will adjust the transmission speed to the capacity of network and receiver. Additionally TCP will retransmit lost packets.

UDP does neither of those. The nc command you used will transmit packets as quickly as it can read the from disk and push them onto the network interface. If the network or the receiving end cannot keep up, it will just keep going at the same speed, and it will send data only once.

If you see only half the data arriving on the other end, it probably means the sending machine is capable of sending the data twice as fast as the rest of the system can handle it.

If you look carefully on the file on the receiving end, you should find that it does not contain just the first half of the original file. Rather you can expect to find fragments from all over the original file.

kasperd
  • 30,455
  • 17
  • 76
  • 124
  • Excellent explanation - thanks! It makes sense to me based on some other things going on with how the server is set up. – Mark Bowytz Aug 22 '14 at 18:16
  • I actually DO use a UDP implementation of rsync for certain low-overhead transfer needs. I'll post details soon. – ewwhite Aug 22 '14 at 18:43
  • @ewwhite UDP is such a thin layer on top of IP, that practically anything which can be done over IP can be done over UDP. Of course a protocol running over UDP can implement its own flow control and retransmission. But that isn't what `nc` is designed for. Rather `nc` is designed to just wrap the underlying transport protocol in a command line utility with as little in between as possible. – kasperd Aug 22 '14 at 19:27