The documentation for nopoll_conn_get_msg() states that the accepted socket will be non-blocking by default. This is not the case when the accepted socket has not enabled TLS.
The following line in the internal accept method states it will set non-blocking, and then it sets blocking.
|
/* configure non blocking mode */ |
|
nopoll_conn_set_sock_block (session, nopoll_true); |
This is not the case for TLS sockets, as evident by this line:
|
/* don't complete here the operation but flag it as |
|
* pending */ |
|
conn->pending_ssl_accept = nopoll_true; |
|
nopoll_conn_set_sock_block (conn->session, nopoll_false); |
Documentation for nopoll_conn_get_msg() states that default is non-blocking
|
* This function is design to not block the caller. However, |
|
* connection socket must be in non-blocking configuration. If you |
|
* have not configured anything, this is the default. |
This confusing behavior has tripped up multiple co-workers of mine, including me for a time, until I fully comprehended both the websocket standard and the nopoll implementation
The documentation for
nopoll_conn_get_msg()states that the accepted socket will be non-blocking by default. This is not the case when the accepted socket has not enabled TLS.The following line in the internal accept method states it will set non-blocking, and then it sets blocking.
nopoll/src/nopoll_conn.c
Lines 4692 to 4693 in e80b74a
This is not the case for TLS sockets, as evident by this line:
nopoll/src/nopoll_conn.c
Lines 4874 to 4877 in e80b74a
Documentation for
nopoll_conn_get_msg()states that default is non-blockingnopoll/src/nopoll_conn.c
Lines 3034 to 3036 in e80b74a
This confusing behavior has tripped up multiple co-workers of mine, including me for a time, until I fully comprehended both the websocket standard and the nopoll implementation