2010/7/3 Peter Bex <[email protected]>: > [...] > 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. _______________________________________________ Chicken-hackers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-hackers
