linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* close() on tcp socket.
@ 2011-04-06 11:00 ratheesh kannoth
  2011-04-06 11:54 ` Javier Martinez Canillas
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: ratheesh kannoth @ 2011-04-06 11:00 UTC (permalink / raw)
  To: linux-c-programming

connect() system call establishes a connection as shown in below steps.

1.   |client |  ----------------- syn --------------->  | server |

2.  |Server|  --------------syn+ ack --------------> | client |

3.  | Client | -----------------ack --------------------> | Server |


But establishing connection , client calls close() system call. Client
is sending FIN+ ACK to server  [ i expected only FIN to be sent from
client to server ]

Is this a valid scenario.?  what could be the problem ?


-Ratheesh

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: close() on tcp socket.
  2011-04-06 11:00 close() on tcp socket ratheesh kannoth
@ 2011-04-06 11:54 ` Javier Martinez Canillas
  2011-04-06 19:20 ` Glynn Clements
  2011-04-17 12:26 ` Mahavir Jain
  2 siblings, 0 replies; 4+ messages in thread
From: Javier Martinez Canillas @ 2011-04-06 11:54 UTC (permalink / raw)
  To: ratheesh kannoth; +Cc: linux-c-programming@vger.kernel.org

On Wednesday, April 6, 2011, ratheesh kannoth <ratheesh.ksz@gmail.com> wrote:
> connect() system call establishes a connection as shown in below steps.
>
> 1.   |client |  ----------------- syn --------------->  | server |
>
> 2.  |Server|  --------------syn+ ack --------------> | client |
>
> 3.  | Client | -----------------ack --------------------> | Server |
>
>
> But establishing connection , client calls close() system call. Client
> is sending FIN+ ACK to server  [ i expected only FIN to be sent from
> client to server ]
>
> Is this a valid scenario.?  what could be the problem ?
>
>
> -Ratheesh

The problem is that both sides can never coordinate to close the
connection. So TCP does the best it can. It notifies the other side
that the connection will be closed and start a timer. If the othet
side gets the FIN + ACK its send an ACK. When the sender gets the ACK
closes the connection. If the ACK doesnt arrive and the timer expires,
it just close the connection, the other side will eventually will
notice that the connection was closed so it will also close its side.
So you dont need a handshacking protocol. In fact you cant design a
robust protocol. This is a particular case of a more general problem
known as the two army problem [1]

[1] http://en.m.wikipedia.org/wiki/Two_Generals'_Problem

Hope it helps,
Javier

-- 
-----------------------------------------
Javier Martínez Canillas
(+34) 682 39 81 69
PhD Student in High Performance Computing
Computer Architecture and Operating System Department (CAOS)
Universitat Autònoma de Barcelona
Barcelona, Spain
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: close() on tcp socket.
  2011-04-06 11:00 close() on tcp socket ratheesh kannoth
  2011-04-06 11:54 ` Javier Martinez Canillas
@ 2011-04-06 19:20 ` Glynn Clements
  2011-04-17 12:26 ` Mahavir Jain
  2 siblings, 0 replies; 4+ messages in thread
From: Glynn Clements @ 2011-04-06 19:20 UTC (permalink / raw)
  To: ratheesh kannoth; +Cc: linux-c-programming


ratheesh kannoth wrote:

> connect() system call establishes a connection as shown in below steps.
> 
> 1.   |client |  ----------------- syn --------------->  | server |
> 
> 2.  |Server|  --------------syn+ ack --------------> | client |
> 
> 3.  | Client | -----------------ack --------------------> | Server |
> 
> 
> But establishing connection , client calls close() system call. Client
> is sending FIN+ ACK to server  [ i expected only FIN to be sent from
> client to server ]

Every TCP packet except the initial SYN-only packet includes an ACK. 
The ACK flag simply indicates that the acknowledgement number field is
valid. Once a host has received at least one packet, any packets which
it sends will always have a valid acknowledgement number and so the
ACK flag will be set.

When the client sends the initial SYN packet to create the connection,
it hasn't received any packets from the server, so it cannot
acknowledge anything. This packet (including any retransmissions of
it) is the only case where the ACK flag will be clear.

> Is this a valid scenario.?  what could be the problem ?

There is no problem.

-- 
Glynn Clements <glynn@gclements.plus.com>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: close() on tcp socket.
  2011-04-06 11:00 close() on tcp socket ratheesh kannoth
  2011-04-06 11:54 ` Javier Martinez Canillas
  2011-04-06 19:20 ` Glynn Clements
@ 2011-04-17 12:26 ` Mahavir Jain
  2 siblings, 0 replies; 4+ messages in thread
From: Mahavir Jain @ 2011-04-17 12:26 UTC (permalink / raw)
  To: ratheesh kannoth; +Cc: linux-c-programming

Hi Ratheesh,

On Wed, Apr 6, 2011 at 4:30 PM, ratheesh kannoth <ratheesh.ksz@gmail.com> wrote:
> connect() system call establishes a connection as shown in below steps.
>
> 1.   |client |  ----------------- syn --------------->  | server |
>
> 2.  |Server|  --------------syn+ ack --------------> | client |
>
> 3.  | Client | -----------------ack --------------------> | Server |
>
>
> But establishing connection , client calls close() system call. Client
> is sending FIN+ ACK to server  [ i expected only FIN to be sent from
> client to server ]
>

Above sequence is correct.

See Q2.7 in following link for more details,
http://www.faqs.org/faqs/unix-faq/socket/

-- 
Thanks,
Mahavir
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-04-17 12:26 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-06 11:00 close() on tcp socket ratheesh kannoth
2011-04-06 11:54 ` Javier Martinez Canillas
2011-04-06 19:20 ` Glynn Clements
2011-04-17 12:26 ` Mahavir Jain

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).