What Happened to Socket If Network Has Broken Down

What happened to socket if network has broken down

There's numerous other ways a TCP connection can go dead undetected

• someone yanks out a network cable inbetween.
• the computer at the other end gets nuked.
• a nat gateway inbetween silently drops the connection
• the OS at the other end crashes hard.
• the FIN packets gets lost.
• undetectable errors: A router in-between the endpoints may drops packets.(including control packets)
  reff

In all cases you can know about it when you try to write on socket this cause through SIGPIPE error in your program and terminate it.

By read() it can't be know whether other-side live or not. Thants Why SO_KEEPALIVE useful. Keepalive is non-invasive, and in most cases, if you're in doubt, you can turn it on without the risk of doing something wrong. But do remember that it generates extra network traffic, which can have an impact on routers and firewalls.

And this affects all sockets on your machine too!(you are correct). And Because SO_KEEPALIVE increase traffic and consume CPU. It's best to set the SIGPIPE handle, if there is a chance application will ever write to a broken connection.

Also use SO_KEEPALIVE at reasonable place in the application. It's poor to use it for whole connection duration (i.e do use so_keepalive when server works for long on client query).

Setting the probing interval Dependends on your application or say
Application layer protocol.

Though enabling TCP keepalive, you'll detect it eventually - at least during a couple of hours.

Say if the network has broken down and however, instead of trying to write, socket is puted into some epoll device :

The second argument in epoll:

 n = epoll_wait (efd, events, MAXEVENTS, -1);

Set with correct event-related code, Good practice is to check this code for

caution as follow.

n = epoll_wait (efd, events, MAXEVENTS, -1);  
for (i = 0; i < n; i++)  
{   
    if ((events[i].events & EPOLLERR) ||
          (events[i].events & EPOLLHUP) ||
          (!(events[i].events & EPOLLIN)))
    {
          /* An error has occured on this fd, or the socket is not
             ready for reading (why were we notified then?) */
      fprintf (stderr, "epoll error\n");
      close (events[i].data.fd);
      continue;
    }

    else if (sfd == events[i].data.fd)
    {
          /* We have a notification on the listening socket, which
         means one or more incoming connections. */
         
         // Do what you wants
     }
}

Where EPOLLRDHUP means is:

Stream socket peer closed connection, or shut down writing half of connection. (This flag is especially useful for writing simple code to detect peer shutdown when using Edge Triggered monitoring.)

What happens to socket when the internet connection goes off suddenly?

The only way to be sure a connection is working is by receiving a heartbeat, or message at a regular interval.

There is isConnectd() which means; have I ever connected and isClosed() which means; did I call close() on my side, but these don't do what you might want.

What happens if the server closes the socket first?

1. When you kill a program having established sockets, it will send RST to all other end. so B should receive RST on s1, and all future call on s1 will return error. But some firewall may filter out the RST packet, you can check the RST packet with tcpdump.

2. If B doesn't receive the RST packet in step1, when it continues sending other packets (write) to A, A will reply with RST packet, and all future call on B will return error once B receive this RST.

3. If B doesn't receive the RST packet in step2 too, after a certain time (write timeout), B will drop the connection, and all future call on B will return error.

You can see, write call seldom return error, it returns success if the packet is send, doesn't care whether the remote end receives the packet.

in your situation, you don't get EPOLLHUP as soon as you call epoll_wait, but after received RST or write timeout

What happens to sockets when I unplug a network cable?

What address are you using for "Con A"? If you are using an address that is bound to the external network adapter, even though you're talking to the same machine, then what you describe could happen.

What you can do is use the address localhost (127.0.0.1) for "Con A", which should be completely independent of what happens on the external network.

Can a TCP socket notice the exception of network broken?

What confused me is there is similar implementation (java.net.Socket) on android, I can catch exception immediately if I set the phone to flight mode.

Not so similar. java.net.Socket does not use select(), except for read timeouts on platforms that don't support SO_RCVTIMEO.

Is select() implementation platform specific?

Of course.

In short, if this method can be used to monitor the network broken?

No.

if not, is there any solution for this?

The only way you can reliably detect a broken TCP connection is to try to write to it. Eventually, after taking into account buffering and retries, write() or send() and friends will return -1 with errno == ECONNRESET.

crash network and consequent state of socket

The first thing to keep in mind is that your computer typically will not know when the "network crashes" per se. All the computer will know is whether or not it is receiving packets from the network, or not. (Some computers might also know if the electrical signal on their local Ethernet port has gone away, but since it is possible for more distant parts of the network to go down without affecting the signal on the local Ethernet cable, that information is only occasionally useful).

In practice, if the network between your computer and (the computer it was talking to) stops working, you'll see the following effects:

(1) Any UDP packets you send will be dropped without a trace, and usually without any error indication. And of course you won't receive any UDP packets from the remote peer either.

(2) Data traffic on any TCP connection between your computer and the remote peer will grind quickly to a halt. After a certain timeout period (usually several minutes) has elapsed without the OS receiving any responses from the remote peer, the operating system will "give up" and mark the TCP connection as closed; at which point you will see behavior identical to what you would get if the remote peer had deliberately closed the connection: that is, select() will return ready-for-read (and possibly ready-for-write also, I forget), and then when you try to actually do a recv() or read() on the socket, you will get an EOF (i.e. recv() on a blocking socket will return 0; recv() on a non-blocking socket will return -1). (if the network recovers before the timeout completes, then TCP traffic on your socket will resume, although it will start resuming slowly and gradually speed up again over time)

---

Related Topics