> Hello everyone, > > I need a deeper understanding of SSL_read()/SSL_write() and was > wondering if someone could please provide some insight. > > As far as I understand, OpenSSL has is a record-oriented protocol. > Lets say the record size is 16K. Let's say a client requests data of > size 40K and then waits on epoll.
I'm not sure exactly what you mean here. Do you mean the client issues a non-blocking SSL_read requesting 40Kb of data and gets a 'WANT_READ' indication and then waits for an epoll read hit on the socket? > 1) Assuming all is well, the server will package the 40K in 3 SSL > records and send them across. Is this correct? What 40K? The server's not going to send 40KB of data just because that's what the client asks for. If the server sends 40KB in a single call to SSL_write, and the server is also using OpenSSL, there's a good chance it will get packaged into three SSL records. But it's certainly not guaranteed. > 2) The client has now 3 SSL records in its network buffer. epoll > returns and the client app issues as SSL_read(). SSL will now read all > the 3 records, if it has sufficient internal buffer, do all the error > checking and pass it on to the application. If SSL's internal buffer > is not large enough, then the data remains in the network buffer. Is > this correct? OpenSSL will attempt to get the application the 40KB it asked for. If it can, it will. If it can't, it won't. > 3) Now, if the client application wants to read all the data, then all > is well. But let's say, the app does not want to read more than 10K. > So after reading 10K, the client is done. But we still have another > 30K of data in the SSL buffer. Now, the same client issues another > request for the same 40K of data from the server. Huh? How could the client do that? Do you mean the client sends a request using some application-level protocol (not SSL) to ask for the same data again? That is, such that the server will send it again? > What happens when > the client receives the new data? Now the SSL buffer will have 30 + 40 > = 70K of data. Will the SSL read pointer still be at the beginning, > meaning the next 10 K to be delivered to the app is really data from > the previous call? It is not data from the previous call since the data was *NOT* retrieved in the previous call. It is a serious confusion of terminology to think of data as being "from the previous call" just because the previous call could have retrieved it but did not. In particular, there is no way the application can tell this is the case. (How can you know there was data you could have retrieved but didn't?) OpenSSL just provides a bidirectional stream of bytes. It doesn't make the record structure visible to the application. If the client asks for 40KB of data from the server using the application protocol, and then the application on the other ends sends that 40KB, and then the client asks for another 40KB of data from the server using the application protocol and the application sends that other 40KB, then there will be 80KB of received data to receive -- received as a stream of bytes with no application-visible record boundaries. It matters not one bit to OpenSSL when the application reads all or some of that data, but it will receives those 80KB of data in the order the application sent them. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
