3

Say a user space application has a TCP connection with some non local endpoint. At some point, network gets abruptly broken (i.e. connection deleted in network manager, unplug the wifi dongle, cut the Ethernet cable)

What is conceptually happening inside the kernel to cope with the situation and how does it manifest itself to the userspace application?

Guideline sub-questions:

  • what are the timeouts involved?
  • will the kernel try to hide from userspace the connection is lost while attempting to reconnect?
  • can waiting for a response cause the userspace app to not want to quit gracefully?
4
  • 1
    There has been a close vote for the question being off topic without a comment what particularity. As I see it the question addressed two topic points. Using or administering a *nix desktop or server and UNIX C API and System Interfaces. Would therefore ask for a comment on the closed vote please. Dec 5 '18 at 13:38
  • I personally voted to leave this open; one vote currently says "too broad" while the other thinks it's a request for learning materials. Since I didn't cast those votes, I can't speak to them.
    – Jeff Schaller
    Dec 5 '18 at 15:50
  • The network interface or other infrastructure going down does not mean the “connection is lost”. TCP will keep trying to retransmit for a long time before killing the connection (9 minutes?). It’s not up to the kernel it is the TCP protocol and the “userspace app” could very well wait until the connection is dropped before exiting. Dec 8 '18 at 5:23
  • @MurrayJensen Your comment is pretty close to an answer. If you can phrase it to address my questions, will accept it as an answer. Mar 15 '19 at 15:21
2

The network interface or other infrastructure going down does not necessarily mean the “connection is lost” - TCP may keep trying to retransmit for a long time before killing the connection (depends what happened - an error on the local interface will probably cause an immediate error, but a router going down somewhere along the path may not).

It’s not up to the kernel, it is determined by the TCP protocol and the “userspace app” could very well wait a long time before receiving an error on the socket.

To answer each sub-question specifically:

  • I've seen suggestions of up to 9 minutes before timeout (I think some of these timeouts might be configurable, where the protocol allows it and things like TCP keepalives can be configured to cause timeouts earlier);
  • the kernel doesn't hide things, or try to "reconnect", it simply follows the TCP protocol, continually re-trying sending of un-acknowledged segments ... the "userspace app" is simply suspended inside the system call (e.g. write(), sendto(), etc) i.e. the "userspace app" is running in kernel mode and it's context is switched out and won't be switched back until some event makes the process "runnable" again;
  • while suspended, the "userspace app" may be "uninterruptible" which means you can't kill it, even if you use SIGKILL (i.e. kill -9) as root - "graceful exit" may not be an option (although, I don't think this can happen with send on a socket, it has to be something that is considered to be short term and high priority - e.g write to a file on NFS with hard mount and intr flag not set can do it) ... but even if it is an option, the "app" must be written to catch errors and exit gracefully itself - if the kernel makes the "app" exit, it won't be graceful :-) (e.g. it won't run exit handlers or free up resources allocated outside the "app", etc)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.