Skip to main content

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.

  1. 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.

  2. SSL_ASYNC_getRecvBuffer: Must be called after SSL_ASYNC_recvMessage2 if there are bytes available for the application to consume. This function will provide access to the plaintext buffer.

  3. 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. If SSL_FLAG_ENABLE_SEND_BUFFER is set, it must be followed by SSL_ASYNC_getSendBuffer to retrieve the cipher text.

  4. SSL_ASYNC_getSendBuffer: Retrieves the cipher text to be sent over the network following a call to SSL_ASYNC_sendMessage.

  5. SSL_ASYNC_sendMessagePending: This function is not necessary if SSL_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.

In this section: