On Thu, Sep 18, 2008 at 2:36 PM, Wan-Teh Chang [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 3:12 PM, Darin Fisher [EMAIL PROTECTED] wrote:
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
Well, yeah I can certainly do that, but it sounded from the thread
that Dan was already heading down that road, and I wasn't sure how far
he'd gotten. In some quick stubbing, I also ran into windows'isms in
UploadDataStream. Wasn't sure about the plan there.
I wasn't sure how much of the wheel I
I thought the plans for mac osx did not involve nss. I think we should do
an implementation based on the mac ssl apis so that we get good integration
w/ the keychain or what have you. right?
-darin
On Fri, Sep 19, 2008 at 12:40 PM, Dan Kegel [EMAIL PROTECTED]wrote:
On Fri, Sep 19, 2008 at
I had thought so, too, but on IRC there was some talk of using nss
but interfacing to the native keyring somehow. So who knows.
On Fri, Sep 19, 2008 at 12:58 PM, Darin Fisher [EMAIL PROTECTED] wrote:
I thought the plans for mac osx did not involve nss. I think we should do
an implementation
I was looking at UploadDataStream a while back. I think the windows'isms
were just for reading a file from disk. I think the recommendation was
to make a very basic File class in base or net for reading/writing to a
file and use that class in UploadDataStream. We may even be able to use
some
On Wed, Sep 17, 2008 at 8:06 PM, Dan Kegel [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher [EMAIL PROTECTED] wrote:
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
On Wed, Sep 17, 2008 at 11:52 PM, Darin Fisher [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 8:06 PM, Dan Kegel [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher [EMAIL PROTECTED] wrote:
One more data point: we'll also need to support SSL over SOCKS one
day, and that
On Wed, Sep 17, 2008 at 3:12 PM, Darin Fisher [EMAIL PROTECTED] wrote:
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
On Thu, Sep 18, 2008 at 2:36 PM, Wan-Teh Chang [EMAIL PROTECTED] wrote:
Since we don't have access to the SSL state machine
inside NSS's SSL library, we have to use PRFileDesc
and PR_Recv and PR_Send, but we don't need to use
PR_Poll. We can call the 'poll' method of PRFileDesc
directly to
On Thu, Sep 18, 2008 at 2:55 PM, Dan Kegel [EMAIL PROTECTED] wrote:
I bet you five bucks we can layer SSLClientSocket on top of
TCPClientSocket by creating a little nspr i/o layer that
talks to a memory buffer. I did this with OpenSSL some time
ago, I figure I can do it with nss, too.
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
On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher [EMAIL PROTECTED] wrote:
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
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
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
14 matches
Mail list logo
