0

Long story short. I made a Websocket server with noPoll.

There seems to bee no way to detect lost connection. All of the functions that should say nopoll_conn connection alive say that connection is good.

However, if you want to use that connection, seg fault, SIGPIPE, occurs.

That should not to be the right way to discover that client hanged up, right?

Have I lost something? while waiting boost 1.66 I am stuck with that.

regards

ap

EDIT:

nopoll_conn_is_ok(conn) says that connection is good and alive and jet writing to the socket produces seg fault, SIGPIPE. For some reason.

Myst
  • 18,516
  • 2
  • 45
  • 67
Ari-Pekka Sihvonen
  • 1
  • I didn't find any `on_close` event handler in the [noPoll manual](http://www.aspl.es/nopoll/html/group__nopoll__ctx.html)... but I'm sure it should be there somewhere. Otherwise, maybe look into [facil.io](http://facil.io) instead, which I authored for Linux/BSD environments. – Myst Oct 07 '17 at 02:30
  • P.S. `noPoll` is a C library, why the C++ tag? – Myst Oct 07 '17 at 02:36
  • Have to look into that, thanks. – Ari-Pekka Sihvonen Oct 08 '17 at 06:12
  • It is in c++ application. – Ari-Pekka Sihvonen Oct 08 '17 at 06:13
  • 1. For future reference, please post extra information as edits to your question rather than an answer... 2. The fact that you will be using the `C` code you're asking about within a `C++` application doesn't mean `C++` is the appropriate tag. – Myst Oct 08 '17 at 11:50
  • I updated my answer in reply to your clarifications. – Myst Oct 08 '17 at 12:08
  • when your questions are answered, please accept and up vote the answer. If it wasn't, feel free to post comments asking for clarification. – Myst Dec 22 '17 at 05:13

1 Answers1

0

EDIT:

Actually, receiving SIGPIPE is almost "normal" for network connection applications.

This is related to the complexity of network operations and their concurrency.

For example, imagine that the other side sent all it's data and closed the connection. On your machine, the socket should still read all the data from the burred (though trying to send data will raise an error)...

...Also, the event loop used by noPoll might receive a HUP polling information (remote disconnection / hang up) and place it in the queue. At the same time, your code might still be running or it might be placed earlier in the event queue. So at the time your code is running, the connection data wasn't updated just yet.

To handle SIGPIPE in your network application (as indicated in this question), you should either ignore the signal or handle it (if any action is required).

Normally people write in:

 signal(SIGPIPE, SIG_IGN);

Another approach might use the updated sigaction system call:

/* setup signal handling */ struct sigaction act, old, old_term, old_pipe; sigemptyset(&act.sa_mask); act.sa_handler = SIG_IGN; if (sigaction(SIGPIPE, &act, &old_pipe)) { perror("couldn't set signal handler"); exit(errno); };

Remember to include signal.h

#include <errno.h>
#include <signal.h>

In C++ the implementation might be slightly different, but this should work for both C and C++ (or so it seems from this question).

ORIGINAL:

I'm not sure I understand your question, but if you're looking to test if the raw socket connection is okay, look into the nopoll_conn_is_ok function.

If you're looking to handle on_close events, than I can't help with that - I couldn't find any on_close event handler in the noPoll manual... but I'm sure it should be there somewhere. Otherwise, maybe look into facil.io instead, which I authored for Linux/BSD environments.

Myst
  • 18,516
  • 2
  • 45
  • 67