* 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).