You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently tls_socket routines follow a state machine dictated by tls engine by issuing synchronous I/O operations on the upstream TSP socket.
For AsyncWrite/Read we must reimplement the entire flow in such that we call only AsyncWrite/Read on tcp socket.
In order to keep the state we must introduce a state variable on heap and track the progress of the operation.
We can chain callbacks of the underlying AsyncWrite/Read calls on tcp socket in order to transition from state to state.
For example, EpollSocket::AsyncWriteSome or AsyncWriteState in io.cc also use heap allocates states to keep track of operations.
One thing to remember: we should also handle the state where both read and write tls operations require reading from socket with NEED_READ_AND_MAYBE_WRITE. With synchronous calls we just yield and stall to avoid contention. with asynchronous it won't work. So in that case only the first operation must do this, and another one should subscribe to the first one completion, and continue when reading from socket is done.
The text was updated successfully, but these errors were encountered:
Currently tls_socket routines follow a state machine dictated by tls engine by issuing synchronous I/O operations on the upstream TSP socket.
For AsyncWrite/Read we must reimplement the entire flow in such that we call only AsyncWrite/Read on tcp socket.
In order to keep the state we must introduce a state variable on heap and track the progress of the operation.
We can chain callbacks of the underlying AsyncWrite/Read calls on tcp socket in order to transition from state to state.
For example, EpollSocket::AsyncWriteSome or
AsyncWriteState
in io.cc also use heap allocates states to keep track of operations.One thing to remember: we should also handle the state where both read and write tls operations require reading from socket with NEED_READ_AND_MAYBE_WRITE. With synchronous calls we just yield and stall to avoid contention. with asynchronous it won't work. So in that case only the first operation must do this, and another one should subscribe to the first one completion, and continue when reading from socket is done.
The text was updated successfully, but these errors were encountered: