1

I'm devising a protocol to be sent via TCP packets that can sometimes send large (video) files between iOS and OSX devices. I've got three questions:

1) What is the maximum size for each TCP packet for good performance? ie: Is it better to get close to 65535 and let TCP break the data up, or try to stay below a certain threshold. If the latter, what?

2) What is the lowest-overhead way of reading data buffers from a file and sending through the TCP socket? As is often the case in Cocoa, there are a number of ways: NSInputStream - NSFileHandle - POSIX file handle

3) What is the lowest-overhead way of appending the data received from the TCP socket to a file? We have: NSOutputStream - NSFileHandle - POSIX file handle

I'm using GCDAsyncSocket for the sockets.

Thanks!

Christopher Schardt
  • 391
  • 3
  • 13

1 Answers1

0

I've found that 8k packets give optimal performance when using gigabit switches. Larger payload sizes suffer when switches drop packets. Gigabit switches tend to be unreliable after about 15 minutes at full rate (overheating?)

Similarly, The TCP/IP receiver should post packets to a separate async thread/gcd queue for file write. This is somewhat counter intuitive... it minimizes tcp window size growing too large.

Posix is faster than cocoa, but not by much. Try buffering 32mb blocks in ram, then call file write once for entire block. 32mb is file system cache magic number. Calling file write for small chunks uses considerable cpu.

Keith Knauber
  • 752
  • 6
  • 13