TLS, threads, and workers

[Ben Laurie]

Roger Dingledine wrote:
>>The reason that TLS links might argue for a multithreaded design is
>>that, with all the TLS implementations I know of, I don't know any good
>>way to separate the SSL handshake crypto operations from the SSL
>>handshake IO operations.  Thus, if we want to put the RSA operations in
>>a separate execution context (i.e., process or thread) in order to avoid
>>high-latency operations, we'll need to put the socket operations there
>>too.
> 
> 
> I don't know about this either way. Ben, your statemachine ssl demo seems
> to be able to yield the encrypted bytes, and then I can put them on the
> network myself. Is that correct? In other words, is there a way for me
> to treat the SSL object as an encryptor/decryptor, and keep it separate
> from the fd?

Yes.

> (But even if this is possible, we'd have to have some way to squeeze
> an SSL object through a pipe and then back again along with the
> answer. Yuck.)

Well, you can choose your source of yuckiness.

>> But you can't pass sockets back and forth across processes; hence
>>threads seem smart.
>>
>>Another option is to go heavily multiprocess: stick _all_ link
>>encryption operations in separate processes from the main onion routing
>>process.  The link encryption processes could send unencrypted cells
>>back and forth from the main OR process.  This could scale poorly, by
>>requiring many processes.
> 
> 
> Yep. My current thoughts are that we should hope to get an onion
> routing network of 200-300 routers. After that we will need to solve the
> restricted topology problem, because we can't expect to stay a clique
> past that. So with the current code I'm looking to handle maybe 500
> connections. Separate processes for each would just be nuts.

500 processes ain't so bad, plenty of websites run that many Apaches.

>>Another option is to accept hiccups while handshakes are going on.  If
>>we later impose some kind of proof of work requirement before beginning
>>the handshake, this might not be so bad.  On the box that the ORs are
>>currently running on, 1024 bit RSA decrypt takes 6 ms, 1536 bit RSA
>>decrypt takes 19 ms, and 2048 bit RSA decrypt takes 36 ms.
> 
> 
> This is a fine mid-term solution (after all, we accept the hiccups right
> now). There's no rush to add threading.
> 
> We should also recognize that we're already partway down this path: we
> are already multiprocess, and we have infrastructure (albeit socketpairs,
> not memory queues) for communicating to/from the workers. On Win32 we
> already use threads (Win32 doesn't support multiprocess well at all),
> though again these are Windows threads rather than pthreads. But overall
> I think this may be a smaller bullet to bite than it sounds.
> 
> 
>>Another option is to try to hack up OpenSSL to separate the crypto parts
>>from the IO parts.  I don't have a lot of confidence here--OpenSSL
>>internals can get complicated, and I don't see any hooks that do what we
>>want.
> 
> 
> Assuming it's not already done (Ben?), if we do this we will want to
> do it such that we can wrap the changes back into the official OpenSSL
> tree. Otherwise OpenSSL will change out from under us and we'll be
> constantly fighting to keep synced. We would need another developer for
> this (and if we get another developer, we have better things to work on).

See my previous response. Its already done.

>>While I don't question Ben's experience, I must add another data point
>>--- Mixminion uses a lightly multithreaded design, and seems to run fine
>>on FreeBSD.
> 
> 
> Mixminion uses python2's thread layer. Does it use the native pthreads
> directly on FreeBSD?
> 
> 
>>"Non-threadsafe libraries" -- OpenSSL (which we're using now) can
>>supposedly be compiled in a thread-safe mode.
> 
> 
> Wait, what do you mean 'can be compiled'? :) Remember that we're using
> OpenSSL because everybody already has it.

Its always threadsafe, you just have to add locking callbacks.

>>So as you can probably tell, I currently regard threading as the least
>>unworkable solution.  But if there's an even less unworkable solution,
>>I'd rather do that instead.
> 
> Robust software engineering is hard.

Robust threaded software engineering is harder.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff