如何在非阻塞套接字上处理OpenSSL SSL_ERROR_WANT_READ / WANT_WRITE
OpenSSL库允许使用SSL_read从基础套接字读取并使用SSL_write对其进行写入。这些函数可能会根据其SSL协议需求（例如，在重新协商连接时），以SSL_ERROR_WANT_READ或SSL_ERROR_WANT_WRITE返回。
我不太了解API希望我如何处理这些结果。
对一个接受客户端连接的服务器应用程序进行映像，建立一个新的ssl会话，使基础套接字成为非阻塞状态，然后将filedescriptor添加到select /
poll / epoll循环中。
如果客户端发送数据，则主循环会将其分派到ssl_read。如果返回SSL_ERROR_WANT_READ或SSL_ERROR_WANT_WRITE，该怎么办？WANT_READ可能很容易，因为下一个主循环迭代可能只会导致另一个ssl_read。但是，如果ssl_read返回WANT_WRITE，应使用什么参数调用它？图书馆为什么不自行发出电话呢？
如果服务器要向客户端发送一些数据，它将使用ssl_write。同样，如果返回WANT_READ或WANT_WRITE怎么办？可以通过重复刚刚调用的相同调用来应答WANT_WRITE吗？并且如果返回WANT_READ，是否应该返回主循环并让select
/ poll / epoll处理这一问题？但是首先应该写的信息呢？
还是应该在写入失败后立即进行读取？然后，当真正的解析器位于mainloop中时，又有什么方法可以防止从应用程序协议中读取字节，然后又不得不在应用程序的郊区进行处理呢？
问题答案：
对于非阻塞套接字，SSL_WANT_READ意味着 “等待套接字可读，然后再次调用此函数”。 ; 相反，SSL_WANT_WRITE表示
“等待套接字可写，然后再次调用此函数”。
。您可以从或呼叫中获得一个SSL_WANT_WRITE或SSL_WANT_READ两个。SSL_read()``SSL_write()
-
问题内容： 为什么有人会喜欢阻止写而不是非阻止写？我的理解是，仅当您想确保写方法返回后，另一端获得了TCP数据包时，才希望阻止写操作，但是我什至不知道这是可能的。您将必须刷新，而刷新则必须刷新 底层操作系统的写套接字缓冲区 。那么，无阻塞套接字写是否有任何缺点？就性能而言，拥有较大的底层写套接字是否会缓冲一个不好的主意？我的理解是，底层套接字写缓冲区越小，当底层套接字缓冲区已满且isWritabl
-
问题内容： 我想创建一个非阻塞连接。像这样： 为此，我使用了另一个线程，无限循环和Linux epoll。像这样（伪代码）： 如果我先运行服务器，然后运行客户端，那么一切正常。如果我先运行客户端，请稍等一会儿，再运行服务器，然后客户端将无法连接。 我究竟做错了什么？也许可以做不同的事情？ 问题答案： 您应该使用以下步骤进行异步连接： 用创建套接字 开始与 如果返回值既不是也不是，则中止并返回错误
-
如另一个问题中所述，当使用Undertow时，所有处理都应该在专用的工作线程池中完成，如下所示： 我知道可用于显式地告诉Undertow在专用的线程池中调度请求以阻止请求。我们可以通过将包装在实例中来修改上面的示例，如下所示： 调用此方法将exchange置于阻塞模式，并创建一个BlockingHttpExchange对象来存储流。当交换处于阻塞模式时，输入流方法变得可用，除了阻塞和非阻塞模式之间
-
下面的代码允许服务器等待客户端连接到（已经绑定的）套接字。它在客户端连接到套接字时终止，或者在“server_run”取值0时终止：这允许代码的其他部分在合适的时候关闭服务器。 根据对另一个帖子（C：non blocking sockets with timeout：how to check if connection request was made？）的回答和评论，这不是一种方法，因为它涉及到
-
另外，除了调用recv函数后检查WSAGetLastError的值之外，是否还有其他方法可以使用TCP套接字库检测网络断开？ 多谢！
-
下面是我用来将套接字设置为非阻塞的代码： 你知道我做错了什么吗？（它在我的Windows构建中运行良好，使用：