Subject: Re: query: using two write() calls in succession

From: [email-masked]
Date: Wed, 28 Mar 2001 13:21:47 +0200

Rick and der Mouse,

I have some doubts regarding your interpretation of the problem. I was 
under the impression that a blocking write (or send) call would block until
it has received an ACK or an RST for data sent and then perform the 2nd write.
I have noticed that this  happens even when I had made two write calls by 
breaking  the request (1+32)  while making the first normal request to the server. 
(check the previous linuxdump.txt file). I have appended relevant parts of it here:

17:31:17.186250 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 1:2(1) ack 1 win 32120 (DF) 
17:31:17.233839 eth0 < asaehv.ce.philips.com.www > wsasa3005.asa-ehv.ce.philips.com.1181: . 1:1(0) ack 2 win 8760 (DF) 
17:31:17.233891 eth0 > wsasa3005.asa-ehv.ce.philips.com.1181 > asaehv.ce.philips.com.www: P 2:34(32) ack 1 win 32120 (DF) 

As you can see, when I make my first write call by sending 1 byte of data, it  waits until 
it receives the ACK and then proceed with the second write. That means, in this case write call
blocks until the server or peer TCP ackowledges the data. (unless using non-blocking 
sockets, or using MSG_DONTWAIT option if used with send() call). Also, in this case, I have not 
disabled Nagle's algoritm. Ofcourse, my linux client is a dual P-II terminal. 

After, looking into all this, is it possible that RST can be received even after the application has already
come out from the first write call ?? ...or its actually the tcp stack that's still not able to detect the RST just
before sending the request data for the second write (as you can see it still detects if some delay is given).  
Maybe something to do with silly window syndrome since I am writing small amount of data... ??

Please enlighten me with comments and/or pointers.

Regards,
Rajiv Chakravorty

---

From: Rick Jones <[email-masked]>
Date: Wed, 28 Mar 2001 10:06:36 -0800

[email-masked] wrote:
> under the impression that a blocking write (or send) call would block
> until it has received an ACK or an RST for data sent and then perform
> the 2nd write.

I am afraid your impression, while perhaps natual to the untainted :),
is incorrect. As often as not, a send/write call to a socket will
complete once the data has been copied into the stack. This is well
before it is ACKnowledged by the remote, or even sent out the wire.

> I have noticed that this  happens even when I had made two write calls
> by breaking  the request (1+32)  while making the first normal request
> to the server. (check the previous linuxdump.txt file). I have
> appended relevant parts of it here:
> 
> As you can see, when I make my first write call by sending 1 byte of
> data, it  waits until it receives the ACK and then proceed with the
> second write. That means, in this case write call blocks until the
> server or peer TCP ackowledges the data. (unless using non-blocking
> sockets, or using MSG_DONTWAIT option if used with send() call). Also,
> in this case, I have not disabled Nagle's algoritm. Ofcourse, my linux
> client is a dual P-II terminal.

What you are seeing in that trace is the Nagle algorithm, implying
nothing about the completion semantics of the write() call against a
socket. I suspect that if you were to run a system call trace on your
program at the same time, you would find that the second write() call
happened before the ACK.

> After, looking into all this, is it possible that RST can be received
> even after the application has already come out from the first write
> call ?? ...or its actually the tcp stack that's still not able to
> detect the RST just before sending the request data for the second
> write (as you can see it still detects if some delay is given). Maybe
> something to do with silly window syndrome since I am writing small
> amount of data... ??

Even on a "blocking socket" a send/write completes once the data is
written into the socket buffer. This is independent of the decisions TCP
makes about when to send data onto the wire. 

If the socket buffer is full, the write() call will block, but only
until enough space is freed via ACK's or _prior_ writes to allow the
data of this write() into the buffer.

I guess the fancier way to say it is that writing data into the
connection is asynchronous from that data being send on the wire.

All splitting writes will do is cause your app lication to run afoul of
the nagle algorithm and take more CPU cycles on the system than it
should.

If you want to detect remote connection close (via FIN) use the
zero-bytes on a recv/read semantic. If you want to detect remote
connection death, implement a keepalive handshake in your app.

rick jones
-- 
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post, but please do NOT do BOTH...
my email address is raj in the cup.hp.com domain...

---

From: arun <[email-masked]>
Date: Thu, 29 Mar 2001 16:09:11 +0530

hi
 Iam new to this. My doubt is this. With what criteria the intial window for TCP is calculated and set. From the tcp code of
linux, I can interpret that the allowable receive buffer is set to a value 32767. The initial window should be less than this
value. Can any one of u explain me why the initial window is chosen less than 32767 and how is that calculation go.

Thanks
-arun

---

From: Bogdan Ghita <[email-masked]>
Date: Thu, 29 Mar 2001 12:53:04 +0100

Hello arun,

The purpose of a small value for TCP initial window is to limit the
inital 'train' of packets. It is up to each TCP sender to decide the
value, but the higher this value the higher the possibility to end up
with a congestion, because the sender would transmit, without 'probing'
the network, all these packets back-to-back. The main problem is usually
not the TCP receiver not being able to cope with the data, but the path
betwen the sender and the receiver being congested.
This is why the initial window has, preferably, a low value

Bogdan

---

From: "David St. Germain" <[email-masked]>
Date: Thu, 29 Mar 2001 13:01:01 -0500

It's always been my understanding that the default initial window size is
512K for purposes of flow control (avoiding the overflow of sender's and
receiver's buffers) and to avoid fragmentation of the TCP PDU until the
MTU - and max receive window - can be negotiated.

Dave.

----- Original Message -----
From: "Bogdan Ghita" <[email-masked]>
To: "arun" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 29, 2001 6:53 AM
Subject: Re: initial window size

> >  Iam new to this. My doubt is this. With what criteria the intial window
for TCP is calculated and set. From the tcp code of
> > linux, I can interpret that the allowable receive buffer is set to a
value 32767. The initial window should be less than this
> > value. Can any one of u explain me why the initial window is chosen less
than 32767 and how is that calculation go.

---

From: "Oleg Vishnepolsky" <[email-masked]>
Date: Thu, 29 Mar 2001 15:51:49 -0500

512K is a bit much for initial size, to say the least. In fact 512 bytes (not kbytes) is what is used by a lot of
tcp stacks when establishing connection with non-local hosts. 512 is really conservative IMHO. 
Days when backbone MTUs were that small are gone long time ago.
For hosts on the local net, mileage varies depending on the stack. I used 8K in my stacks
(OS/2 circa 1990, FlexOS circa 93). I found that given prevalent MTUs back then of 1460,
8k gave me best performance.

Oleg Vishnepolsky
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David St. Germain
Sent: Thursday, March 29, 2001 1:01 PM
To: [email-masked]
Subject: Re: initial window size

Dave.

---

From: Martin McSweeney <[email-masked]>
Date: Thu, 29 Mar 2001 16:14:04 -0500 (EST)

Hmmm... "a bit much", isn't 512K an extremely large window given any
circumstances?

-martin

Martin McSweeney
[email-masked]

---

From: "Oleg Vishnepolsky" <[email-masked]>
Date: Thu, 29 Mar 2001 16:15:40 -0500

I said "to say the least". Gush, my sense of humor failed me ... Next time I will be dead serious. 

Oleg Vishnepolsky
-----Original Message-----
From: Martin McSweeney [mailto:[email-masked]]
Sent: Thursday, March 29, 2001 4:14 PM
To: Oleg Vishnepolsky
Cc: David St. Germain; [email-masked]
Subject: RE: initial window size

-martin

Martin McSweeney

---

From: "David St. Germain" <[email-masked]>
Date: Thu, 29 Mar 2001 18:09:04 -0500

You are quite right of course, I meant 512 is what most OS's default to.

Dave.