From: txm23@sina.com
Hi Jorgen,
Thank you so much for your reply.
I mean A in state fin_wait2 has already received B's Fin request, A knows the
fin_seq, here i mean A received fin request earlier than those pack whose seq
is smaller than fin_seq (considering the network problem) ,which means
A'acked_seq is still less
than fin_seq, so A will go to state time_wait ,right? wait for those not
received pack?
Another question is for server B ,when it will change to last_ack? i read the
source code of linux 1.2 ,it seems after B notified an EOF to application,
then the application calls tcp_close， but in tcp_close,it sends the fins
request and just changes
it's state to fin_wait2 ,rather than last_ack.I am confused that if the
last_ack is required ,or maybe under some scenario ,it is not required ?
Jorgen Grahn於 2018年5月10日星期四 UTC+8上
6時07分54秒寫道：
> On Wed, 2018-05-09, Terry Tan wrote:
> > Hi all,
> >
> > for tcp status fin_wait2, i have a question, which is , if a client
> > of fin_wait2 status can still receive old pack and process them ?
>
> You mean "if A is in FIN_WAIT_2, can its application still receive data
> from B?"
>
> As far as I can tell from Stevens' "TCP/IP illustrated: vol 1, this is
> a "half-close". A has ended its stream of data to B, but the stream
> in the opposite direction is intact. B may send as much as it
> pleases, forever, or until A resets.
>
> /Jorgen
>
> --
> // Jorgen Grahn \X/ snipabacken.se> O o .
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
