Sam Varshavchik wrote: > I want my application to be able to read/write from a TLS session > concurrently, which requires non-blocking socket transport, and I am > trying to figure out how to use the API correctly. I see that the > documentation indicates the gnutls is thread safe; but does that mean > that one thread can be using gnutls_record_send() while another thread > be using gnutls_record_recv() at the same time?
Yes this can be done in a thread safe way without locks. Even fork and read/write from different processes works. The only issue is on gnutls_bye(). To terminate the session properly you should call with SHUT_WR and start reading until EOF (0) is received. > That's one approach that > I am considering. If not, and I have to multiplex a single thread > between reading and writing, I am trying to figure out how to use the > API correctly. So far, I have: > > * If there's something waiting to be written, call gnutls_record_send. > If gnutls_record_send returned GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN, > call gnutls_record_get_direction(), and note its return value. If > gnutls_record_send wrote something, and there's more left to write, take > it from the top. > > * Call gnutls_record_recv. If something was read, process the read data, > and take it from the top again. If gnutls_record_recv came back with > GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN, call > gnutls_record_get_direction(), combine its return value with the return > value after gnutls_record_send() (if applicable), computing the > corresponding combination of POLLIN and POLLOUT, then call poll() to > wait for the required I/O state. > > Also, in an established TLS session, after the handshake completes, if > gnutls_record_recv() or gnutls_record_send() returns > GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN, will > gnutls_record_get_direction() always return 0 after gnutls_record_recv > and 1 after gnutls_record_send(), or are there situations where > gnutls_record_recv() would need to write to the underlying transport, > and gnutls_record_send() would need to read from the underlying > transport, and how would that be squared away with the application's > simultaneous usage of gnutls_record_send() and gnutls_record_recv()? No there is no such case. They behave exactly like recv() and send(). best regards, Nikos _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
