On 2001.12.19, Rob Mayoff <[EMAIL PROTECTED]> wrote:
> It's important to remember that once a TCP connection is established, it
> is bidirectional, but that each direction can be shut down
> independently.
While I agree that this may be the way most modern TCP/IP stacks
are implemented, just looking at RFC793, section 3.5 (Closing a
Connection) ... examine Case 2:
Case 2: TCP receives a FIN from the network
If an unsolicited FIN arrives from the network, the receiving TCP
can ACK it and tell the user that the connection is closing. The
user will respond with a CLOSE, upon which the TCP can send a FIN to
the other TCP after sending any remaining data. The TCP then waits
until its own FIN is acknowledged whereupon it deletes the
connection. If an ACK is not forthcoming, after the user timeout
the connection is aborted and the user is told.
I feel that this implies that if C sends FIN to S, then S "can send
a FIN to the other TCP after sendinga ny remaining data."
The key here is "remaining data" -- presumably, anything that is
currently in the send-queue, but nothing more. (It doesn't say
"continue to send new data" ... only "remaining data".)
To me, this means, "if C sends FIN to S, S can finish sending
whatever it already had queued up, then it'll send a FIN back."
While that's not a "hard abort", it definitely implies that
when S tries to queue up new data to be sent across the socket
(via write() or send() or whatever), it should get an errno ECONNRESET
or even EPIPE, or something like that.
> I think I've read that on some Unix systems, if you call write with 0
> bytes, it will return EPIPE (or raise SIGPIPE) if a RST has been sent. I
> think I've read that on Linux this does not work. I haven't tested it.
Perhaps there's an ioctl() in Linux that'll provide a
non-destructive read-ahead or peek. I don't know of one, though.
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
