Reducing latency in TCP-based streams
Reducing latency in TCP-based streams
- Subject: Reducing latency in TCP-based streams
- From: Thomas Tempelmann <email@hidden>
- Date: Wed, 11 Mar 2009 12:20:29 +0100
I am writing an app which is time-critical in transmitting small amounts of data between two peers over the Internet (i.e. WAN, not just a local network).
I am trying to understand the latencies that may be involved.
I need some clarifications on how the TCP network stack on OS X packages data going in and out. I am looking to optimize my code so that it caues the least possible latency.
First, I understand that sending and receiving UDP datagrams is very straight-forward: If I create a datagram and send it out, it gets into the I/O queue immediately and gets sent out as one packet over, for instance, Ethernet. No delays involved, if the queue is otherwise empty. Correct?
For TCP, though, I assume this works completely different: Since the APIs we get to use in an app (i.e. CFStreams, or BSD sockets or whatever they're called), see the data as a unpackaged stream, and since
TCP is most effective if it uses Ethernet packets at their full capacity, there's some delaying and collecting going on before data ends up on the Ethernet and beyond.
I try to understand those collection mechanisms in order to see if I need to adjust for them.
This all assumes that the amout of data per time is still far below the capacity of the network, i.e. delivery is generally possible without congestion.
Here's an example:Let's assume there's no outgoing network data in queue.
Now I send 2000 bytes to the outgoing network stream.
An Ethernet packet takes roughly 1500 bytes.
Hence, a first packet with the first 1500 bytes from my stream could be sent out immediately.
For the rest, 500 bytes,
some layer might decide to hold off sending it out because there might be more coming, to fill up another Ethernet packet. But after some waiting, it'll surely decide that it's now time to send it out despite it being a smaller then optimal packet.
Is that basically how it works?
If so, I wonder if I can assume that the network stack is able to learn once the physical layer is idle, and then sends out the small (500 byte) packet without further waiting, as it would not pay off waiting any longer as there's now an open window for data anyway (let's ignore potential Ethernet collisions here).
Or will there be a waiting period in any case, thus sending out the 500 bytes later than if I had stuffed it up with another 1000 bytes right away so that it gets sent without delay?
That's basically what worries me:
Can I decrease latency by making sure I stuff more data into the stream to ensure prompt delivery of my actual payload?
In a simpler example:What if I would only send 10 bytes onces every second, but I want these 10 bytes delivered ASAP, using TCP not UDP.
--
Thomas Tempelmann,
http://www.tempel.org/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden