I'm in a deep discussion with a colleague about the basics of connecting a client and server.

I read the wolfSSL manual and ran the Linux as well as Windows versions (on Linux and on a Windows 8.1 via Visual Studio).

The client and server tests use sockets. Each creates a ssl object and calls the ssl_set_fd to associate the ssl object with a socket descriptor after the client does the TCP_Connect and the server finishes the TCP_Accept.

I know that the ssl object has fields which include the connection state of the client and server. These fields are used in the handshake by both. For example, the client's wolfSSL_Connect executes a while loop to wait for the needed state, which nominally would be server_hello_done or something like that.

The underlying socket software, I claim, is allowing both the client and server to access the ssl object between them. If not for the ssl_set_fd, then each executable has its own ssl and the handshake would never complete.

Am I right? Or is there a different way without modifying my wolfSSL to use it without sockets? I'm interested in the context of connection establishment mainly and I am aware of being able to customize input/ioutput with the callbacks (to skip tcp/ip). But the callbacks still do not preclude the use of sockets for a connection establishment.

thanks

Bill