[70] in 6.033-lab
Re: 6.033 Lab questions
daemon@ATHENA.MIT.EDU (David Mazieres)
Fri Feb 27 23:22:13 1998
Date: Thu, 26 Feb 1998 17:42:57 -0500 (EST)
From: David Mazieres <dm@reeducation-labor.lcs.mit.edu>
To: csapuntz@cag.lcs.mit.edu
Cc: dbb@MIT.EDU, 6.033-lab@MIT.EDU
In-Reply-To: <q1bzpje3t41.fsf@tma-1.lcs.mit.edu> (message from Constantine
Sapuntzakis on 26 Feb 1998 17:21:18 -0500)
Resent-To: 6.033-lab-mtg@menelaus.MIT.EDU
Resent-From: "Kevin 'Bob' Fu" <fubob@mit.edu>
> From: Constantine Sapuntzakis <csapuntz@cag.lcs.mit.edu>
> Date: 26 Feb 1998 17:21:18 -0500
Just to clarify:
> 1) Received EOF on read from client - shutdown half of socket that writes
> to server
In other words, call:
shutdown (server_fd, 1);
> 2) Received EOF on write to client - shutdown half of socket that reads from
> server
There really is not such a thing as a write EOF (Sorry about being
ambiguous about this). If write returns 0, you can treat this as an
error. Namely, close the client socket, finish writing any buffered
data you have to the server socket, and close the server socket.
One thing you probably don't ever want to do is call:
shutdown (fd, 0);
because TCP doesn't have any way of letting the other side know that
you have shut down your end of the socket for reading. You can
achieve the same effect as this shutdown command simply by not reading
from a socket.
> 3) Received EOF on read from server - shutdown half of socket that writes to
> client
>
> 4) Received EOF on write to server - shutdown half of socket that reads from
> client.
Case 4 is the same as 2, with client and server swappe.
I'll append the previous mail I sent exmplaining shutdown, in case you
missed it (a few people weren't on the mailing list at the time).
David
***
People asked how their TCP proxies should handle EOF in my recitation.
I'd like to clarify my response as none of the handouts we gave you
talk about the shutdown system call:
int shutdown (int fd, int how);
how == 0 -> reading
how == 1 -> writing
how == 2 -> both
The shutdown system call informs the kernel that one is no longer
interested in reading or writing to a file descriptor. It can be
particularly useful on TCP sockets with how set to 1.
Suppose process A has a TCP socket sa connected to socket sb in
process B on another machine. If A calls
shutdown (sa, 1);
then any future reads B performs on sb (after B has read all the data
A wrote to sa) will return 0, indicating EOF. Though A can no longer
write to sa, it can still read from it. Many applications make use of
the fact that they can continue to read from a socket even after
sending an EOF.
So how should you handle an EOF or error in your TCP proxy? Suppose
s1 and s2 are two sockets, one connected to a client, and one
connected to the server you are proxying. You should be concerned
with the following cases:
A read or write to s1 returns an error (other than EAGAIN), or a
write to s1 returns EOF:
In this case, you can close (s1), finish writing any buffered data
you might have to s2, and then close s2.
A read on s1 returns EOF:
The fact that s1 no longer wants to write data does not mean it
isn't still interested in reading the rest of what arrives on s2.
Thus, you should pass on the EOF by calling shutdown (s2, 1)
after writing any buffered data you might have for s2.
If you subsequently read an EOF from s2, then no more data will be
sent in either direction. You can close (s2), finish writing any
buffered data you might have to s1, and close s1.
This situation is symmetric. You can exchange s1 and s2 in the text
above.
David
