disabling the send delay on TCP

Started by
26 comments, last by GameDev.net 19 years, 3 months ago
well how would u do it in c++. Ill translate that to vb.
Advertisement
char output_data[504];
char string_user_just_typed[500];
int text_len;

text_len=strlen(string_user_just_typed);
output_data[0]=text_len;
strcp(&output_data[1],string_user_just_typed);
alrite thx man, thx alot
Quote:Original post by jake_Ghost
alrite thx man, thx alot


Np, ask if you have more questions.
BTW, unless you plan to send just data, I'd suggest you use the first byte for what kind of data you are planing to send (text, log in info, etc.)
Also, my example is very rudimentary, it assumes that the length is only up to 256 bytes (in fact, char, in C, can be signed or unsigned, so the length might be -127/128
Quote:Original post by hplus0603
The delay usually used per socket is on the order of at least 200 milliseconds -- the whole idea behind the option is to send one packet instead of two when the user is typing fast in telnet clients. (Yes, that's why it was invented!)


I think this is a (common) misunderstanding of Nagle. It does not delay packets for a fixed amount of time. It works different, though it might look the same on first sight.

What Nagle does is not sending small segments (where small means smaller than the MSS) as long as there is an unacknowledged packet outstanding. Lets say you write 10 small packets to your socket. The first will be send right away because there is no outstanding ACK. The second packet however will not be sent until the ACK from the first packet arrives. So the delay is fully dependant on the latency. Basicly Nagle avoids that you send more packets over the network than the other side can process to avoid congestion.

The 200ms delay comes from another TCP-feature, the delayed ACK. TCP delays the ACK for up to 200ms, waiting for a data-packet, so it can piggy-pack it on a data-packet. If there is no data-packet within this delay, the ack will be sent without data. This reduces the number of packets on the network. But because Nagle waits for the ACk before sending the next packet, this can be bad at times.


Well, at least this is how I understood it ;)
schue: Yes, your description is correct. Thanks for being more specific. For the record, I believe the delayed ack is part of silly windows avoidance, and is mandated by the TCP spec. Although the exact delay is only required to be LESS than 500 ms, with no lower bound.
enum Bool { True, False, FileNotFound };
http://homebrew.icarusindie.com:2004/LifeOnLine/

Source code is available for the client which includes a self contained client side TCP winsock class in a single h file.

The short version is do not send messages immediatly. Buffer them and then send them all out one per main loop iteration. This increases efficiency a lot since fewer headers are sent. You then just have to make sure your main loop is running fast.

You also then want to buffer messages as they come in rather than trying to process them immediately. Only process messages once per main loop. Continue reading the buffer until all the complete messages are taken care of.



That should be "once per main loop iteration"

If you generate 20 messages in a single loop they should all be put on the wire at the same time. Not individually as they're created.

This topic is closed to new replies.

Advertisement