Thread: Unix Nonblocking Reads on Sockets

  1. #1
    Registered User
    Join Date
    Sep 2008
    Posts
    3

    Unix Nonblocking Reads on Sockets

    Hi,

    I admittedly do not know alot about unix socket programming. I have been given some code that I need to fix and I am hoping someone here could point me in the right direction.

    So currently I have an application that connects to a socket and performs nonblocking reads/writes on it. The problem I have is that if you disconnect the ethernet cable the program just dies.

    What I know is that I need to close the socket when I detect a disconnect. After that I imagine I should periodically try to reconnect until successful.

    What I don't know is how to detect the disconnect when performing a read or a write. It seems that these operations just set errno to EWOULDBLOCK and go on their merry way.

    Could someone tell me how to detect disconnects on nonblocking read/write operations?

    thanks

  2. #2
    Registered User valaris's Avatar
    Join Date
    Jun 2008
    Location
    RING 0
    Posts
    507
    recv will return 0 on a disconnect I believe. You can also set a timeout on these operations.

  3. #3
    Registered User
    Join Date
    Sep 2008
    Posts
    3
    Hi Valaris,

    Thanks for replying. As for recv, I believe it will return 0 if there are no bytes read and set errno equal to EWOULDBLOCK.

    I'm not sure what the timeouts would be for. This is a non-blocking operation. If there happens to be no data to read, I just want to keep going.

  4. #4
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    You cannot detect a "disconnect." This is because there is no such thing. Pulling the ethernet cable is not a "disconnect," it simply causes packets to stop reaching their destinations. TCP is designed to be robust against such events. If a packet cannot be immediately delivered to the local hardware, whether this is due to a pulled cable or an attack from outer space, you would get an EWOULDBLOCK error code.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  5. #5
    Registered User
    Join Date
    Sep 2008
    Posts
    3
    Quote Originally Posted by brewbuck View Post
    You cannot detect a "disconnect." This is because there is no such thing. Pulling the ethernet cable is not a "disconnect," it simply causes packets to stop reaching their destinations. TCP is designed to be robust against such events. If a packet cannot be immediately delivered to the local hardware, whether this is due to a pulled cable or an attack from outer space, you would get an EWOULDBLOCK error code.
    Hi Brewbuck,

    Thanks for the reply. What you say makes sense. So when the cable is unplugged my non-blocking reads will just return EWOULDBLOCK and go merrily on their way. When I plug the cable back in the data will begin to get delivered again and be available for reading on my socket, right?

    I guess I was thinking TCP connections were a direct connection to a ip/port on a server and once that connect was broken the sockets would need to be closed/reopened when the link became available again. Am I right in saying this is not the case?

    What if the server dies when the connection is broken?

    I really appreciate your help.

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    There is no absolute guarantee that a packet arrives. If your application wishes to ensure that a particular system at the other end "is still there", you'd need to have regular traffic from the system you need to know is there. You could send some "I'm Alive" packets if there's no data to transmit. If there is nothing arriving for a set amount of time (a few seconds or minutes), then you close the connection. If the other end "reawakens" later on, then it will get a reply of the type "sorry, but I thought you were gone, please log on again".

    If you are trying to send to something that "isn't there any longer", you'd presumably get EWOULDBLOCK after a while of trying (once you've filled the local buffer). Once you get EWOULDBLOCK, you check how long you keep getting that message, and if it lasts for more than X seconds, you give up and say "I'll try again later".

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Unix sockets
    By karas in forum Linux Programming
    Replies: 8
    Last Post: 10-13-2007, 12:20 AM
  2. Difference between Unix sockets and winsock.
    By antex in forum Networking/Device Communication
    Replies: 15
    Last Post: 01-21-2005, 04:53 PM
  3. Winsock vs Unix Sockets
    By khoxxxy in forum Networking/Device Communication
    Replies: 4
    Last Post: 08-05-2003, 05:13 AM
  4. Unix Sockets
    By prvindia in forum Linux Programming
    Replies: 5
    Last Post: 03-11-2003, 09:16 AM
  5. new to unix sockets
    By lithium in forum C Programming
    Replies: 3
    Last Post: 01-20-2003, 05:53 AM