如何在非阻塞套接字上处理OpenSSL SSL_ERROR_WANT_READ/WANT_WRITE [英] How to handle OpenSSL SSL_ERROR_WANT_READ / WANT_WRITE on non-blocking sockets

查看:1537
本文介绍了如何在非阻塞套接字上处理OpenSSL SSL_ERROR_WANT_READ/WANT_WRITE的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

OpenSSL库允许使用SSL_read从基础套接字读取并使用SSL_write对其进行写入.这些函数可能会根据SSL协议的要求(例如,在重新协商连接时)以SSL_ERROR_WANT_READ或SSL_ERROR_WANT_WRITE返回.

The OpenSSL library allows to read from an underlying socket with SSL_read and write to it with SSL_write. These functions maybe return with SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE depending on their ssl protocol needs (for example when renegotiating a connection).

我不太了解API希望我如何处理这些结果.

I don't really understand what the API wants me to do with these results.

想象一个服务器应用程序接受客户端连接,设置一个新的ssl会话,使基础套接字成为非阻塞状态,然后将filedescriptor添加到select/poll/epoll循环中.

Imaging a server app that accepts client connections, sets up a new ssl session, makes the underlying socket non-blocking and then adds the filedescriptor to a select/poll/epoll loop.

如果客户端发送数据,则主循环会将其分派给ssl_read.如果返回SSL_ERROR_WANT_READ或SSL_ERROR_WANT_WRITE,该怎么办? WANT_READ可能很容易,因为下一个主循环迭代可能会导致另一个ssl_read.但是,如果ssl_read返回WANT_WRITE,应使用什么参数调用它?图书馆为什么不自行发出电话呢?

If a client sends data, the main loop will dispatch this to a ssl_read. What has to be done here if SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE is returned? WANT_READ might be easy, because the next main loop iteration could just lead to another ssl_read. But if the ssl_read return WANT_WRITE, with what parameters should it be called? And why doesn't the library issue the call itself?

如果服务器要向客户端发送一些数据,它将使用ssl_write.同样,如果返回WANT_READ或WANT_WRITE怎么办?可以通过重复刚刚调用的相同调用来应答WANT_WRITE吗?并且如果返回WANT_READ,是否应该返回主循环并让select/poll/epoll处理这一问题?但是首先应该写的信息呢?

If the server wants to send a client some data, it will use ssl_write. Again, what is to be done if WANT_READ or WANT_WRITE are returned? Can the WANT_WRITE be answered by repeating the very same call that just was invoked? And if WANT_READ is returned, should one return to the main loop and let the select/poll/epoll take care of this? But what about the message that should be written in the first place?

还是应该在写入失败后立即进行读取?那么,当真正的解析器位于主循环中时,又有什么方法可以防止从应用程序协议中读取字节,然后又不得不在应用程序的郊区进行处理呢?

Or should the read be done right after the failed write? Then, what protects against reading bytes from the application protocol and then having to deal with it somewhere in the outskirts of the app, when the real parser sits in the mainloop?

推荐答案

对于非阻塞套接字,SSL_WANT_READ表示等待套接字可读,然后再次调用此函数." ;相反,SSL_WANT_WRITE表示等待套接字可写,然后再次调用此函数." .您可以从SSL_read()SSL_write()调用中获得SSL_WANT_WRITESSL_WANT_READ.

With non-blocking sockets, SSL_WANT_READ means "wait for the socket to be readable, then call this function again."; conversely, SSL_WANT_WRITE means "wait for the socket to be writeable, then call this function again.". You can get either SSL_WANT_WRITE or SSL_WANT_READ from both an SSL_read() or SSL_write() call.

这篇关于如何在非阻塞套接字上处理OpenSSL SSL_ERROR_WANT_READ/WANT_WRITE的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆