Re: [lwip-users] TCP FIN question

[Yadnesh Phadke]

Thanks you for the clarification.  But I feel that, this would always put a restriction, that if client want to close connection it should RST.  Otherwise the server will wait till timeout and then end that connection from it's side.  

I have a simple server, that waits in recv().  When it gets any data from the client, it sends back the same data, and again waits on recv().  
Now, the server has not got anything to send, till client sends data.  
Client sends FIN and ACK for data received from server.  I expected the server to respond with a FIN in this case.

Another related question, How would the client come to know that server has sent all the data that it wanted to send?  Is there any specific flag used?  

Regards,
Yadnesh Phadke

On 9/14/06, Kieran Mansley <address@hidden> wrote:

On Thu, 2006-09-14 at 15:10 +0530, Yadnesh Phadke wrote:

> Why is this the case when, TCP documentation says that the client is
> expected receive FIN from the server?  Is the client always expected
> to send RST to close connection from it's side?  And FIN is used only
> for closing connection initiated by the server?

TCP connections are duplex, i.e. data can go in both directions, and
each direction is closed independently.  The FIN means "I've finished
sending data in this direction", not "close the connection in both
directions".  The server will send a FIN when it has finished sending
data (i.e. when the server application calls close()).

If you really really must close a connection now and not care about any
data getting lost, then you can use a RST, but it's not meant for normal
closing of connections.

Kieran



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users