...
http-c.h/http-c.c
Prototype
Code Block |
---|
CPU_BOOLEAN HTTPc_WebSockSend (HTTPc_CONN_OBJ *p_conn_obj,
HTTPc_WEBSOCK_MSG_OBJ *p_msg_obj,
HTTPc_WEBSOCK_MSG_TYPE msg_type,
CPU_CHAR *p_data,
CPU_INT32U payload_len,
HTTPc_FLAGS flags,
HTTPc_ERR *p_err) |
Arguments
p_conn_obj
Pointer to the HTTPc Connection Object for which to open the socket.
...
The connection object p_conn MUST has been previously upgraded to WebSocket to use this function. Refer to the HTTPc_WebSockUpgrade() function.
The available Message Types are :
HTTPc_WEBSOCK_MSG_TYPE_TXT_FRAME
HTTPc_WEBSOCK_MSG_TYPE_BIN_FRAME
HTTPc_WEBSOCK_MSG_TYPE_CLOSE
HTTPc_WEBSOCK_MSG_TYPE_PING
HTTPc_WEBSOCK_MSG_TYPE_PONG
Payload Content:
The "Payload data" (argument p_data) is defined as "Extension data" concatenated with "Application data".
Extension data length is 0 Bytes unless an extension has been negotiated during the handshake.
"Extension data" content and length are defines by the extension negotiated. If negotiated, the "Extension data" must be handled by the Application.
Data message Restrictions:
Even if the RFC6455 allow to sent message payload up to 2^64 bytes, Only 2^32 bytes is allowed in the current implementation.
Control message Restrictions:
According to the RFC 6455 section 5.5: "All control frames MUST have a payload length of 125 bytes or less and MUST NOT be fragmented."
Close frame have a specific payload format. Refer to the HTTPc_WebSockFmtCloseMsg() function for more information.
Client-to-Server Masking
According to the RFC 6455 section 5.2: "All frames sent from the client to the server are masked by a 32-bit value that is contained within the frame."
The Application DO NOT need to mask the payload since it's handled by the WebSocket module.
...