tcp packets and unix.

[Peter Gillis]

Hi, ux11.00 RP2470.
Does anyone have any ideas on how I can check on our unix system how tcp packets are dealt with. We have been watching data over our network and can see that data coming from unix server is being sent character by character. Each character makes up one packet. Every packet is acknowledged. How can I get one whole data field to be sent over the network as one packet?
I know this all sounds like I know nothing, well that is because I dont know, so any info would be of great value to me.
Thanks very much,
Regards Maria.

[Steven E. Protter]

I'd start with this tool:

http://hpux.connect.org.uk/hppd/hpux/Gtk/Applications/ethereal-0.9.15/

It is a sniffer but you can track any and every packet you wish with it.

SEP

[Mark Grant]

It certainly shouldn't be being sent a character at a time. My networking expertise starts to get a bit hazy at this point but my understanding is that there are different sized "blocks" and the network stack uses whichever size is the most efficient and then sends that as one packet. Could be wrong here.

However, the system should not send 1 character at a time. Have a look with SEP's sniffer and see if it is only once application that is causing this grief.

[Brian Hackley · Accepted solution]

Maria,

If your users are typing telnet packets to the HP-UX Server telnetd, then yes they do get sent and responded to one character at a time. You can use the -TCP_DELAY option to telnetd in /etc/inetd.conf, then run inetd -c to make the changes permanent. See the telnetd man page.

If the users are typing rlogin/remsh/rexec sessions they do not have this same feature available. If they are using some other program, then that program has to determine how it sends packets over the network.

Hope that helps,
-> Brian Hackley

[Sean OB_1]

Brian,

What happens if you turn on TCP_DELAY and you have an app where single key strokes are common?

Am I correct in assuming that it will wait until either buffer timeout or buffer size is exceeded and then send the packet?

[Brian Hackley]

Sean,

Yes if using telnetd -TCP_DELAY option and using single keystroke echo of the input you may see some delays of the echos depending on the time between keystrokes, etc. More tunables can be found in ITRC Knowledge base doc # KBRC00013953 "HP-UX 11.x Telnetd Tuning for Performance". Also man 7p tcp for explaination of the TCP_NODELAY setsockopt() option which telnetd uses by default; general infos on expected behaviors of TCP socket options are also explained in TCP/IP Illustrated, Volume 1 by W. Richard Stevens, Addison-Wesley.
HTH, Brian H.

[rick jones]

Another source of discussion of TCP_NODELAY can be found via googling for "nagle TCP_NODELAY"

Basically, the only time one _really_ needs to disable the Nagle algorithm is when you have an application with pseudo-realtime requirements that is sending a continuous stream of small packets (like the X protocol). otherwise, the only time it gets disabled is when someone has a broken application that is sending "logically associated" data to TCP in separate sends.

so, if say an application sent an escape sequence a byte at a time, there could be some noticable delays as the first charater was sent, then the TCP ACK was awaited, then the rest of the characters are sent.

if the applicatoins are written "correctly" they will send all logically-associated data to TCP at the same time - as in the entire escape sequence together.

folks had enough such buggy applications that the telnet team decided (against my advice :) to make TCP_NODELAY the default. IMO all that really did was find those customers with devices that couldn't deal with a large burst of character at a time screen updates.