Alan Cox <alan(at)lxorguk(dot)ukuu(dot)org(dot)uk> writes:
>> No, it doesn't "hang for all eternity", it sits in the same state until
>> (a) the client side closes its sending side of the connection (ie, sends
>> FIN), or (b) the FIN-WAIT-1 state times out. But given a normally
>> responsive client and no loss of physical connectivity or crash of
>> either TCP stack, there is no connection reset and no failure to deliver
>> sent data.
> I cannot ack the data since it has not been read, so how can I ack the fin ?
ACK does not mean that you've delivered the data to the end user.
RFC 793, 2.6:
An acknowledgment by TCP does not guarantee that the data has been
delivered to the end user, but only that the receiving TCP has taken
the responsibility to do so.
Bit-bucketing the data because the end user app is no longer present to
accept it (due to having already closed its input socket) is implicitly
within the receiving TCP's authority here. I think this is the core of
our disagreement, but I can see no justification for your position that
ACK implies the data has been delivered to the end user. Every TCP
implementation I've ever heard of sends ACK as soon as it's collected
data into kernel buffers, *not* after the application has executed
recv() to extract the data from the kernel. (Who's to say that
completion of recv() represents final delivery of the data anyway?
Sending ACK cannot be considered a report of end-to-end delivery;
that has to be an application-level concept.)
Also observe that the discussion of segment-arrival processing in
section 3.9 explicitly says that the behavior in FIN-WAIT-1 and later
states is not different from the behavior in ESTABLISHED state. In
particular, if you do not like the segment:
If an incoming segment is not acceptable, an acknowledgment
should be sent in reply (unless the RST bit is set, if so drop
the segment and return):
After sending the acknowledgment, drop the unacceptable segment
There is no room here for the TCP to decide to send RST instead.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Jan Wieck||Date: 2000-07-04 00:52:38|
|Subject: Re: Re: [COMMITTERS] TOAST|
|Previous:||From: Tom Lane||Date: 2000-07-04 00:11:22|
|Subject: Re: Re: [COMMITTERS] TOAST |