How do I keep a TCP socket open?

[Bill Engelke]

I have a program which acts as a server; I want it to listen on a port.  Sometimes, many hours go by before any traffic comes to the port; I think this port is timing out and closing.

What is the correct way to keep this port open when using libuv? I have looked at a variety of ways to do this (e.g., setting socket options, etc.) but I don't know which is best for use in libuv...

[Ben Noordhuis]

On Wed, Aug 5, 2020 at 4:48 PM Bill Engelke <enge...@bellsouth.net> wrote:
>
> I have a program which acts as a server; I want it to listen on a port. Sometimes, many hours go by before any traffic comes to the port; I think this port is timing out and closing.
>
> What is the correct way to keep this port open when using libuv? I have looked at a variety of ways to do this (e.g., setting socket options, etc.) but I don't know which is best for use in libuv...

If the socket listens on a port (i.e., is a server socket), there
should be no issue with long periods of inactivity. (It's a different
story with peer sockets but I infer that's not what you mean.)

If the port becomes unreachable after a while, it's possible you have
a time-based firewall rule somewhere that closes it off.

[Bill Engelke]

OK.  I think my problem lies elsewhere; I think I have a bug in the program -  I think the program is crashing or getting a signal to quit. Then the port it was listening on (of course) doesn't respond any more.

Are there any circumstances where something in libuv issues a SIGKILL, or other signal, or something like that because it has detected an error?

[Brian Hamon]

Check your system logs for oom_killer. Linux reaps processes that hog memory when system memory is low.

--
You received this message because you are subscribed to the Google Groups "libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libuv+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/libuv/104edfe7-0635-4530-aa5b-434f13078116o%40googlegroups.com.

[Philip Prindeville]

I think he’s referring to connected sockets.

See SO_KEEPALIVE in socket(5).

[Ariel Machado]

I assume you are talking about TCP connections, not UDP.

Are you saying that the listen port (server socket) stops accepting new fresh connections or you're talking about an accepted connection that stops receiving data after a period of inactivity?

 
If you are talking about an established connection, there may be a timeout problem due to inactivity, in which case using keep alive (uv_tcp_keepalive) should resolve the situation.
 

If you're talking about the socket that started listening for incoming connections and stops accepting new connections after a while, it seems a little strange, logs if uv_listen's callback (uv_connection_cb) is invoked and what the status value is, or if your application was actually killed by an unhandled signal.

 
About handling signal errors, you can use uv_signal_start, in addition problably be a good idea handle SIGPIPE (http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#The_special_problem_of_SIGPIPE)
 
You can use an approach like this:
 

int requested_shutdown;
uv_signal_t sig_int;
uv_signal_t sig_term;

void system_signals_start(void) {
  signal(SIGPIPE, SIG_IGN);  
  uv_signal_init(uv_default_loop(), &sig_int);
  uv_signal_init(uv_default_loop(), &sig_term);
  uv_signal_start(&sig_int, signal_shutdown, SIGINT);
  uv_signal_start(&sig_term, signal_shutdown, SIGTERM);
}
 
void system_signals_stop(void) {
  uv_signal_stop(&sig_int);
  uv_close((uv_handle_t *)&sig_int, NULL);
  uv_signal_stop(&sig_term);
  uv_close((uv_handle_t *)&sig_term, NULL);
}
 
static void signal_shutdown(uv_signal_t *handle, int code) {
  fprintf(stderr, "Signal received: %d\n", code);
  if ((code == SIGINT) || (code == SIGTERM))
    requested_shutdown = 1;
}
 
void system_shutdown(void) {
    system_signals_stop();
   ...
}

 
 


:

[WILLIAM n SUSIE ENGELKE]

Thanks for the very good suggestion on including signal handlers; I was aware that this could be done in principle but was fuzzy on how to do it when using libuv.  

The OP referred to a TCP connection, but I discovered that the problem was not due to the port closing, but rather the program itself halting.  I found out what my error was that was causing the program to halt was something silly - an instruction to close a file handle was missing, so it kept creating new file handles with every heartbeat, which (after 6 or 8 hours) would cause an error and halt the program. 

--
You received this message because you are subscribed to the Google Groups "libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libuv+un...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/libuv/5700f701-1cd4-426d-a4c5-e6e42d956423o%40googlegroups.com

.