Understand TCP and SSL functions
Reading from TCP Sockets: Blocking vs. Non-Blocking Modes
When working with TCP sockets in NanoSSL, understanding the behavior of blocking versus non-blocking modes is essential. A socket in its default state is in blocking mode. This means that read operations on the socket will wait indefinitely for data to arrive if no timeout is specified.
The PLATFORM_TCP_readSocketAvailable
function uses the msTimeout
parameter to decide how long to wait for data to become available on the socket. A timeout value of zero (msTimeout = 0
) does not wait and attempts to read immediately, which can block if the socket is in the default blocking mode and no data is available.
For non-blocking operations, you must explicitly set the socket to NON_BLOCKING
mode using the provided API functions.
Writing to TCP Sockets with Non-Blocking Behavior
When implementing the PLATFORM_TCP_writeSocket
function for non-blocking sockets, it’s important to handle scenarios where data cannot be sent immediately. If there’s no room to send data, the function will not block; instead, it will return ?QUESTION: ERROR MESSAGE RETURNED?
and set the bytes written to zero. This allows the calling process to handle this situation without getting stuck waiting for the socket buffer to free up.
Behavior of SSL_send and SSL_sendPending
The SSL_send
function in NanoSSL is designed to handle both blocking and non-blocking sockets. When operating over non-blocking sockets, SSL_send
can return with only partial data sent, and the application should call SSL_sendPending
to ensure all data is eventually sent. However, when using blocking sockets, SSL_send
will block until all the data has been sent.
Non-Blocking Reads and SSL_recvPending
If you’re dealing with a blocking socket and you specify a timeout of zero, the SSL_recv
function will wait indefinitely, which is often not the desired behavior. To perform a non-blocking read, you should set the socket to NON_BLOCKING
mode or use a minimal timeout value.
Handling Asynchronous Operations with SSL_ASYNC API
The SSL_ASYNC API provides functions for asynchronous SSL communication over non-TCP transport layers such as EAP for secure wireless connections. This set of functions allows for the sending and receiving of SSL messages asynchronously.
SSL_ASYNC_recvMessage2
: It processes received data and returns the number of bytes that are ready to be used by the application. If all data is processed, it returns zero for the number of bytes remaining; otherwise, it indicates how many bytes are left to be consumed.SSL_ASYNC_getRecvBuffer
: Must be called afterSSL_ASYNC_recvMessage2
if there are bytes available for the application to consume. This function will provide access to the plaintext buffer.SSL_ASYNC_sendMessage
: Used to send plaintext data. Note that the number of bytes sent might be less than the input size due to encryption expansion. IfSSL_FLAG_ENABLE_SEND_BUFFER
is set, it must be followed bySSL_ASYNC_getSendBuffer
to retrieve the cipher text.SSL_ASYNC_getSendBuffer
: Retrieves the cipher text to be sent over the network following a call toSSL_ASYNC_sendMessage
.SSL_ASYNC_sendMessagePending
: This function is not necessary ifSSL_FLAG_ENABLE_SEND_BUFFER
is set, as the sending buffer will be managed automatically.
By understanding and correctly implementing these functions according to the operation modes (blocking or non-blocking), you can efficiently manage SSL communications within NanoSSL.