UNIX Socket FAQ

A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

  • Index
  • » Networking
  • » Socket (connected) File Descriptor after TCP Connection RESET !!!

#1 2014-04-25 07:54 AM

KewlGuy1
Member
From: Hyderabad
Registered: 2012-07-11
Posts: 8

Socket (connected) File Descriptor after TCP Connection RESET !!!

Trying to develop a concurrent TCP Server with only select() system call.Let us say if the connected client reset the already Established connection; how the application can know it in better way and delete (CLEAR) the corresponding socket fd from the list of FD_SET ? If the TCP State machine move from ESTABLISHED to TIME_WAIT state; still the connection holds for that TIME_WAIT interval (default 60 seconds) and later connection will be removed by Linux Kernel. If the connection itself was removed ; what about the corresponding file descriptor ?? was it removed by Kernel instantly??

Offline

#2 2014-04-25 12:06 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,826
Website

Re: Socket (connected) File Descriptor after TCP Connection RESET !!!

Let us say if the connected client reset the already Established connection; how the application can know it in better way and delete (CLEAR) the corresponding socket fd from the list of FD_SET ?

Well, if the peer really reset the connection (ie: a TCP RST was sent), I/O on your end will fail with errno of ECONNRESET...  If you're sitting in select() at the time, the socket FD will select as readable, and a subsequent read will then fail...  If the peer terminated the connection via some other method (just closing its end of the connection, or fell off the network, or whatever), the errno will differ, but it's all detectable the same way: your socket will select readable, and I/O will fail...  (Well, in the case of a normal proper close on the peer's end, reads will just return zero, which isn't "failing" per se...)  That's where you should be catching all disappearing clients: where you do your I/O...  Whenever that fails (or reads return zero), consider the client gone, close your end of the socket, and remove it from your fd_sets...

If the TCP State machine move from ESTABLISHED to TIME_WAIT state; still the connection holds for that TIME_WAIT interval (default 60 seconds) and later connection will be removed by Linux Kernel. If the connection itself was removed ; what about the corresponding file descriptor ?? was it removed by Kernel instantly??

The file descriptor goes away as soon as you close() it...  Any resources associated with it go away when they're no longer needed...  (Eg: if you closed a socket immediately after doing a write on it, and the peer still had its end open, the kernel would keep the send buffer for it around until it could successfully send that last message out to the peer...  This is assuming no tweaking of SO_LINGER, anyway...)

TIME_WAIT sockets only appear on the side of whoever performed the active close of the connection...  Ie: whoever sent the first FIN; essentially, whoever first did a close() or shutdown(SHUT_WR)...  They are solely in kernel space, and won't exist until the associated file descriptor has already been closed by your app...

Offline

#3 2014-04-29 11:27 AM

KewlGuy1
Member
From: Hyderabad
Registered: 2012-07-11
Posts: 8

Re: Socket (connected) File Descriptor after TCP Connection RESET !!!

Thanks for the detailed response. Able to solve the issue by having an if condition (<=0) for return value of "recv" function. Later., FD_CLR, close(socket fd) did the job.

Offline

  • Index
  • » Networking
  • » Socket (connected) File Descriptor after TCP Connection RESET !!!

Board footer

Powered by FluxBB