[Chicken-hackers] Re: Problem with OpenSSL and file descriptors (sendfile)

[Thomas Chust]

2010/7/3 Peter Bex <address@hidden>:
> [...]
> I've traced an issue with Spiffy in HTTPS mode to a nasty interaction
> between OpenSSL and sendfile.
> [...]
> In order to get the fastest performance, sendfile extracts the file
> descriptors from the given ports if available and uses them in the
> call to those underlying mmap/sendfile POSIX functions.
>
> Now, it turns out that openssl's ssl-accept stores the raw file
> descriptors it receives from the underlying call to tcp-accept in
> the input and output ports it creates.  This means that when you use
> the nice Scheme port abstraction everything will be fine; it uses
> SSL_write() when you write to the port, causing the data to be wrapped
> in SSL protocol stuff.  However, when you extract the descriptor using
> port->fileno, you get the raw TCP descriptor and when you write
> something to that, you screw up the SSL protocol conversation.
> [...]

Hello,

it's long ago that I wrote the OpenSSL binding code for CHICKEN, and I
don't remember any compelling reason to put the raw file descriptors
into the same slot as for other ports, except the reason of
consistency and interoperability between SSL ports and other ports
backed by file descriptors.

For the correct operation of the OpenSSL binding itself, the presence
of the file descriptor in the port should be irrelevant. And if
necessary, the file descriptor could always be retrieved from the
native SSL object using SSL_get_fd(3SSL).

In my eyes it is always a dangerous idea to apply port->fileno to a
port and use the resulting file descriptor for actual input and
output in contrast to some management operation like file-select. For
example, even in the simple situation where a port is connected to a
file, using the file descriptor directly bypasses the stdio buffering
mechanisms and can interact badly with scheme code operating on the
port instead of the raw descriptor. The stdio layer is also allowed to
perform transcoding operations so that writing to the raw file
descriptor instead will result in different disk contents. It's not
only OpenSSL that behaves strangely here!

Anyway, if enough people feel like breaking the existing API and
providing a set of alternative functions from the OpenSSL egg would be
a good idea, by all means go ahead and do it :-)

Ciao,
Thomas


-- 
When C++ is your hammer, every problem looks like your thumb.