Nanomsg error not reported for nn_recv when socket is unbinded

user_10359701 0
Viewed 101

I have created a receiving socket, using nanomsg library and trying to nn_recv() a message as code below shows :

recv_bytes = nn_recv ( socket_id, &buf, NN_MSG, 0 );

when the recv_bytes was < 0, I do following :

    if ( recv_bytes <= 0) {

         struct nn_polld pfd[1] ;
        
         pfd[0].fd = socket_id;
         pfd[0].events = NN_POLLIN;
            
         rc = nn_poll ( pfd, 1, 2000 );

         if ( rc == 0 ) {
              printf ( "Timeout!" );
           // exit (1);
         }

         if ( rc == -1 ) {
              printf ( "Error!" );
           // exit (1);
         }
            
         if ( pfd [0].revents & NN_POLLIN ) {
              printf ( "Message can be received from s1!" );
           // exit (1);
         }
    }

I don't see Error! text at all, I always see other prints, but not receiving any messages until I rebind to socket.

I wanted to know if there is any way that i can get error through NN_POLL and reconnect/bind again. Problem is I don't want to do it randomly upon a timer.

Please suggest.

I am unable to receive messages from the end-point, when one of the end-stations got closed. If I know nanomsg socket has gone bad, then I can rebind but not getting any error and at the same time no messages are received from other end stations too.

nanomsg low-latency distributed-computing tcp sockets
1 Answers

Q : " I wanted to know if there is any way that i can get error through NN_POLL and reconnect/bind again. "

A :
First, welcome to the lands of distributed-computing signalling & messaging. Nanomsg is a smart, younger child of Martin Sustrik, co-father of the ZeroMQ system. The original Zen-of-Zero ( you can always read more about these core-ideas & evangelisation elsewhere else) has Martin put another step further, when setting up the nanomsg - so if ZeroMQ spent zero-steps more than was necessary for meeting its ZMTP-RFC specifications and still being smart & scalable, nanomsg tries to spend even less on its own grounds -- long story short -- do not expect neither the ZeroMQ, the less the nanomsg, to spend a single CPU-tick on anything more, than what was documented & "contracted" to happen over the API (which in exchange for having ultimate performance, scalability & minimum latency is a piece of art & a generous deal for us, common-code mortals, isn't it?).

What we CAN do ?

Let's start from the Documented API :

...
Upon successful completion, the number of nn_pollfds structures with events signaled is returned. In case of timeout, return value is 0. In case of error, -1 is returned and errno is set the one of the values below.

ERRORS

EBADF
Some of the provided sockets are invalid.
EINTR
The operation was interrupted by delivery of a signal before the message was sent.
ETERM
The library is terminating.

Given this, you are fair to expect receving -1 in errno if-and-only-if at least one of documented incidents happen ( hierarchy is self-explanatory )
(a)
your code-side nanomsg infrastructure-node detected a (self)-termination already going on, or

(b)
in case of not-(a), the code-side nanomsg-node has been interrupted by O/S- or USR-SIGNAL ( and having obeyed it, it has returned without a work finished - self-reporting your code, it was interrupted ), or

(c)
in case of not-(a) && not-(b) it also has to report a case, when your code has asked a nanomsg-node to operate a non-nanomsg socket ( or an O/S-socket filehandle ), so it does so
and
in all other cases, the returned value will never be other than { 0 | n_events }, thus never { -1 }

Some aid might be sourced from nn_get_statistic ( aSock, anOptionCODE ):

...
NN_STAT_ESTABLISHED_CONNECTIONS The number of connections successfully established that were initiated from this socket.
NN_STAT_ACCEPTED_CONNECTIONS The number of connections successfully established that were accepted by this socket.
NN_STAT_DROPPED_CONNECTIONS The number of established connections that were dropped by this socket.
NN_STAT_BROKEN_CONNECTIONS The number of established connections that were closed by this socket, typically due to protocol errors.
NN_STAT_CONNECT_ERRORS The number of errors encountered by this socket trying to connect to a remote peer.
NN_STAT_BIND_ERRORS The number of errors encountered by this socket trying to bind to a local address.
NN_STAT_ACCEPT_ERRORS The number of errors encountered by this socket trying to accept a a connection from a remote peer.
NN_STAT_CURRENT_CONNECTIONS The number of connections currently estabalished to this socket.
NN_STAT_MESSAGES_SENT The number messages sent by this socket.
NN_STAT_MESSAGES_RECEIVED The number messages received by this socket.
NN_STAT_BYTES_SENT The number of bytes sent by this socket.
NN_STAT_BYTES_RECEIVED The number of bytes received by this socket.
...

yet, the actual design & application-code decision-making of these API-delivered details is yours

user_36661970
Related