noPollConn* nopoll_conn_new ( noPollCtx ctx,
const char *  host_ip,
const char *  host_port,
const char *  host_name,
const char *  get_url,
const char *  protocols,
const char *  origin 
)

Creates a new Websocket connection to the provided destination, physically located at host_ip and host_port (IPv4 version).

Parameters
ctxThe noPoll context to which this new connection will be associated.
host_ipThe websocket server address to connect to.
host_portThe websocket server port to connect to. If NULL is provided, port 80 is used.
host_nameThis is the Host: header value that will be sent. This header is used by the websocket server to activate the right virtual host configuration. If null is provided, Host: will use host_ip value.
get_urlAs part of the websocket handshake, an url is passed to the remote server inside a GET method. This parameter allows to configure this. If NULL is provided, then / will be used.
originWebsocket origin to be notified to the server.
protocolsOptional protocols requested to be activated for this connection (an string of list of strings separated by a white space). If the server accepts the connection you can use nopoll_conn_get_accepted_protocol to get the protocol accepted by the server.
Returns
A reference to the connection created or NULL if it fails. Keep in mind the connection reported may not be connected at the time is returned by this function. You can use nopoll_conn_is_ready and nopoll_conn_is_ok to ensure it can be used. There is also a helper function (NOTE it is blocking) that can help you implement a very simple wait until ready operation: nopoll_conn_wait_until_connection_ready (however, it is not recommended for any serious, non-command line programming).

Note 1: Is nopoll_conn_new blocking?

Partially. It is blocking with a timeout but just for sending the client init (the initial packet that a WebSocket client must send), but the function does not block the caller until a reply from the server is received and the handshake is completed (which is where the blocking it is likely to happen).

So, it essence, nopoll_conn_new (and all its variants) is not blocking (unless you have a problem with network connection causing send() API to fail to send the WebSocket init message by returning EWOULD_BLOCK, which is very likely to not happen),

Because of that, the connection (noPollConn) reported by this function have big chances to be not ready (that's why you have to use nopoll_conn_is_ready or the blocking one nopoll_conn_wait_until_connection_ready to ensure you successfully connected),

Note 2: Controll connect timeout

To control timeout for sending the initial message (and to ensure the engine sends it), you can use the following functions:

References nopoll_false, and NOPOLL_TRANSPORT_IPV4.