site_archiver@lists.apple.com Delivered-To: macnetworkprog@lists.apple.com --- Thomas Tempelmann <tempelmann@gmail.com> 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_TCPReliabilityandFlowControlFeaturesandProt... --- Marshall Eubanks <tme@multicasttech.com> 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 (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com