One more data point: we'll also need to support SSL over SOCKS one day, and that means that the ClientSocket passed to SSLClientSocket will not be a TCPClientSocket. it will be a SOCKSClientSocket. the SOCKSClientSocket will be layered on top of another ClientSocket, which will be the TCPClientSocket. this extra layering would only happen of course when a SOCKS proxy is enabled.
This should clarify why we need to parameterize SSLClientSocket in terms of ClientSocket. -darin On Wed, Sep 17, 2008 at 3:12 PM, Darin Fisher <[EMAIL PROTECTED]> wrote: > On Tue, Sep 16, 2008 at 9:42 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: >> >> Here's what I'm thinking, please yell if it sounds wrong. >> >> 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. > > non-blocking connects done on the calling thread, leveraging the fact > that the calling thread has a ML of TYPE_IO. > > >> >> 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. > > let's try very hard to use TCPClientSocket and avoid using NSPR + > PR_Poll for TCP sockets. what we really want is to just use the > state-machine portions of NSS. i know that might not be easy to get > access to, but it is what we should aim for. > > >> >> 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. > > can't we avoid NSPR? or does the NSS shipped with existing Linux > boxes give us no alternative API to get at the SSL state machine? > > >> >> 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. >> Having done this once before with openssl, >> I expect this will be a pain. But what the heck, >> it should be fun, too. >> >> Whew. Thanks for reading, sorry it was so long. >> - Dan >> >> related issues: >> http://code.google.com/p/chromium/issues/detail?id=2134 >> http://code.google.com/p/chromium/issues/detail?id=1317 >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
