TCP, Small Packets, PSH bit, TCP_NODELAY

TCP, Small Packets, PSH bit, TCP_NODELAY

Post by Vincent Boni » Wed, 14 Feb 2001 08:43:15



Help!

i'm optimizing a client/server app and i have noticed a couple of things
that i cannot explain. i am using rh6.2 and libc sockets.

- all packets generate by the application have PSH bit set. why is that?
i thought the PSH bit was set by the stack when it needs to force the
packet onto network.
- each calls to write OR send generate a new packet, independent of
packet size (4-100 bytes) and of the TCP_NODELAY option. i thought that
by defaults small loads are not sent over the network unless a timeout
occurs.
- btw, why is the write() call supposed to set the push flag by default
(source: google)? is it also the case for the send() call?
- if TCP_NODELAY is set, the client/server may still wait (connection at
steady-state) for an ack from the server/client to send a small packet
and this even though the advertised window is large (link largely
unused). what may make tcp wait outside congestion/advertized windows
and nagle?
- would one know of a funky tcp timer whose default value is around
20ms?

same occurs on rh6.1 and rh7.0

i can provide straces and tcpdumps if you need them.

thanks
vincent

--

Institut fuer Neuroinformatik        tel.:    +41 1 635 3033
ETH / Universitaet Zuerich           fax:     +41 1 635 3053
Winterthurerstrasse 190, Haus 55     www:     www.ini.ethz.ch
CH-8057 Zurich, Switzerland.

 
 
 

TCP, Small Packets, PSH bit, TCP_NODELAY

Post by Manfred Bart » Wed, 14 Feb 2001 09:45:38



> i'm optimizing a client/server app and i have noticed a couple of
> things that i cannot explain. i am using rh6.2 and libc sockets.

> - all packets generate by the application have PSH bit set. why is
> that?  i thought the PSH bit was set by the stack when it needs to
> force the packet onto network.

The PSH flag is one of those things that looked like a good idea at
the time, but AFAIK is no longer important.  There is usually no means
of setting it from the application and the stack would normally be
smart enough to set it whenever the currently transmitted packet
empies the transmit buffer.  Most (all?) receive ends disregard the PSH
flag because they never hold received data back from the application.

Quote:> - each calls to write OR send generate a new packet, independent of
> packet size (4-100 bytes) and of the TCP_NODELAY option. i thought
> that by defaults small loads are not sent over the network unless a
> timeout occurs.
> - btw, why is the write() call supposed to set the push flag by
> default (source: google)? is it also the case for the send() call?
> - if TCP_NODELAY is set, the client/server may still wait
> (connection at steady-state) for an ack from the server/client to
> send a small packet and this even though the advertised window is
> large (link largely unused). what may make tcp wait outside
> congestion/advertized windows and nagle?
> - would one know of a funky tcp timer whose default value is around
> 20ms?

> same occurs on rh6.1 and rh7.0

> i can provide straces and tcpdumps if you need them.

The Nagle algorithm basically says (for small packets) that if
unacknowledged data exists on the transmit side, new data will not
be sent until an acknowledgement arrives.  Because acks are very
fast on a LAN, you will have difficulty observing the algorithm
in that environment.

For a more authoritative answer than I can provide you could repost
your question in ``comp.protocols.tcp-ip''.   :)

Cheers
--
Manfred
---------------------------------------------------------------
ipchainsLogAnalyzer, NetCalc, whois at: <http://logi.cc/linux/>

 
 
 

TCP, Small Packets, PSH bit, TCP_NODELAY

Post by Vincent Boni » Sat, 17 Feb 2001 04:43:08


thanks for your help, very appreciated.

vince

--

Institut fuer Neuroinformatik        tel.:    +41 1 635 3033
ETH / Universitaet Zuerich           fax:     +41 1 635 3053
Winterthurerstrasse 190, Haus 55     www:     www.ini.ethz.ch
CH-8057 Zurich, Switzerland.

 
 
 

1. Q) Sockets & TCP load with small packets ?

Hi,

We have several hundred networked client machines dotted around various
buildings. I have done a really small program that runs on a fixed port and
waits for a hello packet, like a ping. On receiving this ping it sends back
a 80byte packets with some stats about the client machine.

I am in the process of writing the server app that will basically do:

for (i=0;i<NoClients;i++)
    Send(hello packet to client i)

and will wait for incoming packet from the clients. What i am worried about
is because i am sending the hello packet to everyone and on receiving the
clients will send a reply back instantly will the sockets/TCP be able to
cope or will it be like a miny DOS attack and result in many errors and
dropped packets etc...

I would like to have implemented it using UDP but due to the packet size, at
the moment being 80bytes and possibly growing, i guessed TCP would be the
best method.

So basically my question is, if i have several hundred clients all sending
small data packets back to one machine, what would be the best way to
implement this so the receiving machine copes with the number of incoming
packets?

At the moment i sitting with some basic blocking sockets code and a while
loop with a recv() in it but am not sure if non-blocking, or a multi
threaded model or another methods would be more appropriate.

Thanks,
Scott

2. Red Hat 8.0 Russification

3. iptables tcp-logged ACK PSH

4. Linux and windows 2000

5. TCP flag PSH - (Sorry for the cross-posting)

6. NIS+ bibliography

7. TCP : no FIN PSH ACK

8. Pivotting LCD monitors in linux

9. How to convert TCP/IP packet to IPX packet and visa-versa ?

10. Create TCP syn packet with given seq num and few other TCP parameters

11. Tracing TCP/IP packets from NIC to TCP

12. TCP/IP: Slow packets every so often, even with the TCP patch.