is it Nagle?

[Omar Balbuena]

Hello!

I have sniffed the communication between a PLC and a software I am
maintaining. We're introducing TCP/IP communication. There is an
unexplained, unacceptable delay of about 0,35 seconds between every ACK
and SEND here. See messages 4 and 5, or 8 and 9:
http://balbuena.com.br/aae/2007/undesired-delay.pcap
Loading Image...

I am absolutely sure this has nothing to do with software processing,
because such thing never happened with serial ports and modem
communication using the exact same layers. After some research, I've
discovered it seems to be the Nagle Algorithm that's slowing me down,
and I've added the proper lines of code and it seems to have no effect.
But this looks like absolutely anything but Delayed Ack.

My question is:
Is it really Nagle?
If it is, do any of you have any example of some complete Winsock2
application that manages to disable it?
If it's not, what is it and how do I disable it in Winsock2?
How could I switch to Delayed Ack using Winsock2?
*OR* Is there a better alternative than Winsock2 for developing a TCP/IP
layer for a small message protocol into a Windows C++ non-MFC DLL?

[Bill Meier]

Post by Omar Balbuena
After some research, I've
discovered it seems to be the Nagle Algorithm that's slowing me down,
and I've added the proper lines of code and it seems to have no effect.
But this looks like absolutely anything but Delayed Ack.
Is it really Nagle?

My answer would be no;

I seem to remember that the Nagle delay happens only when there is
outstanding unacknowledged previously sent data when new data is provided by
the program to the TCP stack.

After frame 4 there is no outstanding unacknowledged data so I doubt that the
delay before 4 and 5 is due to Nagle.

That being said, I've no knowledge or experience of how Winsock works so the
above may or may not apply.

I do note one somewhat interesting thing.

The window size specified by ...129 is decreasing as it receives and acks
data (65040, 65031, ...).
Altho perfectly OK, this is an indication on some (many ?) TCP stacks that
the data is buffering up in the stack and not being processed by the
receiving program.

Post by Omar Balbuena
I am absolutely sure this has nothing to do with software processing,
because such thing never happened with serial ports and modem
communication using the exact same layers.

Bill Meier

[Marco Rommelse]

Hi,

The delay between packet 3 and 4 (0.133 sec.) is due to nagle, as is the
delay between packets 7 and 8 (0.161 sec.). The delays of about 0.30 seconds
between 4 and 5 as well as 0.46 sec. between 8 and 9 are probably not. My
guess would be that this could be caused by program delay.

Nagle is used to keep chattiness under control, an efficiency measure. In
essence it's a sort of timer. Standard for many tcp stacks is that this
timer fires every 200 ms. When the stack has received some data it will wait
sending acknowledgements for data that the program wants to send out. If
that data doesn't come before the timer fires, it will acknowledge the
outstanding data. Now, for telnet for instance this would mean that you will
see a delay between you are typing a character and it being echoed back.
This is why sometimes you want to disable it.
The following quote I have found for winsock programming:
"The Nagle algorithm is on by default in Winsock, but it can be turned off
on a per-socket basis with the TCP_NODELAY option of setsockopt(). This
option should not be turned off except in a very few situations."

The quote comes from: http://tangentsoft.net/wskfaq/intermediate.html


Marco Rommelse


-----Oorspronkelijk bericht-----
Van: wireshark-users-***@wireshark.org
[mailto:wireshark-users-***@wireshark.org] Namens Omar Balbuena
Verzonden: vrijdag 20 juli 2007 16:42
Aan: wireshark-***@wireshark.org
Onderwerp: [Wireshark-users] is it Nagle?

Hello!

I have sniffed the communication between a PLC and a software I am
maintaining. We're introducing TCP/IP communication. There is an
unexplained, unacceptable delay of about 0,35 seconds between every ACK
and SEND here. See messages 4 and 5, or 8 and 9:
http://balbuena.com.br/aae/2007/undesired-delay.pcap
http://balbuena.com.br/aae/2007/undesired-delay.png

I am absolutely sure this has nothing to do with software processing,
because such thing never happened with serial ports and modem
communication using the exact same layers. After some research, I've
discovered it seems to be the Nagle Algorithm that's slowing me down,
and I've added the proper lines of code and it seems to have no effect.
But this looks like absolutely anything but Delayed Ack.

My question is:
Is it really Nagle?
If it is, do any of you have any example of some complete Winsock2
application that manages to disable it?
If it's not, what is it and how do I disable it in Winsock2?
How could I switch to Delayed Ack using Winsock2?
*OR* Is there a better alternative than Winsock2 for developing a TCP/IP
layer for a small message protocol into a Windows C++ non-MFC DLL?
--
Omar M. Balbuena N.
Canopus Informática Ltda
Porto Alegre - RS - Brasil
[phone]
http://www.canopusonline.com/

_______________________________________________
Wireshark-users mailing list
Wireshark-***@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users