Understanding Send-Q and Recv-Q by netstat
in [Linux Networking]
|
Prev: 2.6.31 and connmark restore are not really working for fwmarking and policy routing
Next: ug+w problem on share mounted from XP
From: David Schwartz on 5 Dec 2009 03:29 Oh, and before you say set and read socket buffer sizes are the same, try this program: #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/socket.h> int main(void) { int j, i; socklen_t l; j=socket(AF_INET, SOCK_STREAM, 0); if(j<0) return -1; i=16384; l=sizeof(i); if(setsockopt(j, SOL_SOCKET, SO_RCVBUF, &i, l)!=0) return -2; if(getsockopt(j, SOL_SOCKET, SO_RCVBUF, &i, &l)!=0) return -3; printf("recvbuf=%d bytes\n", i); close(j); } It does not fail, but the output is *NOT* 16,384. DS
From: Christophe Lohr on 7 Dec 2009 07:10 So, there are two points: - set and read socket buffer size are not the same (2 times larger) - Send-Q and Recv-Q may containts headers (but in TCP it contains user data only, isn't it?) So let's play with ad-hoc lient / server (see attached files) $ ./lazyServerTCP 8003 SO_RCVBUF=4000 SO_SNDBUF=4000 $ ./clientTCP localhost 8003 SO_RCVBUF=4000 SO_SNDBUF=4000 80715 $ netstat -tpn Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name tcp 65930 0 127.0.0.1:8003 127.0.0.1:47969 ESTABLISHED 16937/lazyServerTCP tcp 0 14784 127.0.0.1:47969 127.0.0.1:8003 ESTABLISHED 16939/clientTCP I see that Recv-Q plus Sed-Q equals the amount of user data sent. However I can't figure out why Recv-Q is 16 times larger than the actual socket buffer...? Regards. --
From: David Schwartz on 7 Dec 2009 08:35 On Dec 7, 4:10 am, Christophe Lohr <christophe.l...(a)enst-bretagne.fr> wrote: > However I can't figure out why Recv-Q is 16 times larger than the actual > socket buffer...? Why should one have anything to do with the other? You're measuring two completely different things and wondering why the measurements are different -- well why shouldn't they be? The receive buffer is something you at socket level. The Recv-Q is something at TCP level. The receive queue size may affect how fast the receive buffer can grow, but it won't directly affect its ultimate maximum size. DS
From: Christophe Lohr on 7 Dec 2009 10:34 David Schwartz a �crit : > >> However I can't figure out why Recv-Q is 16 times larger than the actual >> socket buffer...? > > Why should one have anything to do with the other? You're measuring > two completely different things and wondering why the measurements are > different -- well why shouldn't they be? Let's play with wireshark. Do a "Follow TCP stream". The amount of user data sent before the TCP window becomes zero is equal to Recv-Q So, I understand the definition of Recv-Q: The count of bytes not copied by the user program connected to this socket. > The receive buffer is > something you at socket level. The Recv-Q is something at TCP level. Well, but netstat gives a Recv-Q per socket... (a TCP socket in my case) > The receive queue size may affect how fast the receive buffer can > grow, but it won't directly affect its ultimate maximum size. .... sorry, I don't understand what are socket receive/send buffers :-( This is another level of buffer? What is in it? Is it after or before Recv-Q (along data flow within the socket) Regards Thank you for your explanations and your patience
From: Rick Jones on 7 Dec 2009 14:10
David Schwartz <davids(a)webmaster.com> wrote: > Why should one have anything to do with the other? Perhaps this is decades of BSD-based precedent interacting with Linux's desire to be different? rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... |