On Wed, Dec 16, 2015 at 06:23:25PM +0000, Martin Brampton wrote: > Is there a way to obtain the amount of data available to be read? > > I'm working with a system that operates in non-blocking mode using epoll. > When an EPOLLIN event is received the aim is to read the data. For the > non-SSL case, the amount of data can be obtained using ioctl FIONREAD. This > is used to malloc a suitable sized buffer, followed by read the data into > the buffer. > > How should the SSL version of our code work? At present it is using the sum > of the number obtained from ioctl FIONREAD (which seems suspect when SSL is > in use and appears to be always too large) and the number from ssl_pending > (which seems to be zero). The buffer then has to be truncated. Please note that SSL_pending() returns the data about already processed / decrypted TLS records. If the record is not complete it's not processed and we won't tell how big it is. This means that it's possible for SSL_pending() to return 0 and that receiving a single byte for the kernel might make the whole packet available. If you then go and only read 1 byte, calling SSL_pending() will actually tell you how many other bytes are still has available for you that already passed all the checks. So the library can have unprocessed bytes from a TLS record in it's internal buffer, but it's not going to tell you much about it. SSL / TLS also has overhead, the data might also not even be application data. Also, some ciphers work in blocks so there might be added padding for those blocks. So there are various reasons why you might receive less data too. If you always call SSL_read() on the boundaries of the records you'll always get less data, but there is really no way for you to see that. It might be that in your application this is always what happens, but I wouldn't rely on it. If you don't call in on the boundaries there is little you can predict about the size you're going to get. Kurt
