On Tue, Sep 16, 2008 at 9:42 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: > When we implement SSLClientSocket on linux, > we can do it with one-thread-per-connection, > or with nonblocking I/O. > Since all socket I/O goes through the browser process, > one thread per connection would limit us to > however many stacks fit in the address space > (on my box, with the default stack size, about 380). > Seems obvious to me that we want nonblocking rather than > one-thread-per-connection, but I figured I'd mention the > choice before we start plunging into the port.
I think in general we've avoided using threads for networking except where absolutely necessary -- the only instance that comes to mind is DNS resolution. I think nonblocking better matches what we're doing on Windows. > There's another design choice to make: > whether to write an NSPR I/O layer so we can use > our own TCPClientSocket for all network I/O, > or bypass TCPClientSocket and let nss do its > own I/O. Wan-teh suggests the latter is easier in > http://developer.mozilla.org/En/PR_ImportTCPSocket > but I think that requires us to use > http://developer.mozilla.org/en/PR_Poll to do > I/O multiplexing in MessagePumpForIO, > and to base TCPClientSocket on NSPR. > > In previous discussion with Darin, it seemed we > wanted to use epoll rather than poll. This > implies that we want to not use NSPR for our > network I/O, and thus implies that we want to > write an NSPR I/O layer so we can do our own > network I/O rather than letting nss do it via nspr. Here are some other considerations that might influence your decision: - does about:network monitor only TCPClientSocket connections, or am I at the wrong abstraction level? if it does, then it would be good for SSL to fall into the same category - is there an interaction here with the max-connections-per-host limit? I don't have anything useful to say, really. The latter option sounds better to me. > Happily, Howard Chu recently posted a partial > example of how to do the latter, > http://groups.google.com/group/mozilla.dev.tech.crypto/msg/af4b5b6c71b70702 > > I think the next step might be for me to write an > app demonstrating how to handle 500 > simultanous ssl connections using nss and libevent. Above you wrote "epoll" but here you write "libevent". Do you have a preference? If you want libevent, might I suggest libev (http://software.schmorp.de/pkg/libev.html)? It's based on libevent but without the obnoxious advertising clause. But any extra library dependency brings us again to the 64/32-bit library distribution issues that have been super-annoying. > Having done this once before with openssl, > I expect this will be a pain. But what the heck, > it should be fun, too. Aw, I recently did something similar with gnutls and it wasn't bad. Remember that openssl is generally the upper bound on how difficult a library can be to use. :) One final suggestion: since we're nearing completion on the webkit branch merge landing, we'll soon begin poking into more of webkit. It would be useful for parallelization of development if we had a working HTTP stack sooner rather than waiting longer for both HTTP+HTTPS. So if you can land TCPClientSocket before dealing with all the NSS complexity I think that would be useful. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
