Re: Reducing latency in TCP-based streams
Re: Reducing latency in TCP-based streams
- Subject: Re: Reducing latency in TCP-based streams
- From: email@hidden (David E. Gelhar)
- Date: 11 Mar 2009 08:41:46 -0400
--- Thomas Tempelmann <email@hidden> wrote:
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?
--- end of quote ---
No, I don't think so.
In general*, the TCP stack is not going to deliberately delay waiting for the
application to give it more data so it can "fill up the packet". [* - The exception
is if there's already an un-acknowledged packet in transit; see RFC 896]
Consider that many TCP-based protocols (such as IMAP and SMTP) involve sending
commands (which may be quite short) then waiting for a response; in this environment
a full-sized packet is the exception rather than the rule.
It's also important to understand that TCP is making its decisions on when it
can send more data based on end-to-end considerations (such as the receiving systems'
advertised receive window, congestion control, etc.; see RFC 2001), not on whether
the local ethernet is busy.
Here's an online TCP guide has a lot of information on TCP retransmission and
flow control:
http://www.tcpipguide.com/free/t_TCPReliabilityandFlowControlFeaturesandProtocolMod.htm
--- Marshall Eubanks <email@hidden> wrote:
You haven't really said anything about what you are trying to do, but if I were
you I would consider using UDP with RTP to provide for sequence numbers on the
data, so the application at the far end would know if data were dropped. If your
data sizes are small, you should consider RTP header compression as well.
In general, don't reinvent the wheel, especially if you are not sure what the
wheel is actually doing.
--- end of quote ---
Yep. I would say that the choice of TCP or UDP+RTP depends on what your priority
is: low latency or guaranteed delivery. In particular, if you find yourself implementing
retransmission timers, duplicate detection, flow control, etc. on top of UDP,
you might be better off just using TCP.
_______________________________________________
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