On Thu, Jul 21, 2005, James Yonan wrote: > I'm the lead developer of the OpenVPN project, and there's a long-standing > latency issue I'd like to resolve. > > OpenVPN uses memory BIOs to interact with the OpenSSL TLS implementation > (OpenVPN uses TLS + DH). During the TLS negotiation, there's obviously a > lot of bignum crunching going on, and some of the calls to BIO_read end up > taking a relatively large amount of CPU cycles before returning. On a > 2Ghz P4, the worst-case delay can be 160 milliseconds for a 2048 bit key. > > Because OpenVPN is commonly used in a single threaded environment, this > BIO_read call ends up locking up the main event loop for 160 milliseconds > or more. While this might not be noticable for an FTP transfer, it's > potentially bad news for real-time streaming protocols such as VoIP or > video. > > One solution to this problem, of course, is to use multithreading. While > certainly an option, multithreading carries a lot of extra baggage with > it, and I was hoping there might be a solution to the problem that stops > short of requiring multithreading. > > So my question: > > (a) Does any facility exist within OpenSSL that might used to limit the > worse-case latency of BIO_read calls without requiring multithreading? > > (b) If the answer to (a) is no, can you give me any initial starting > pointers on how I might go about writing code to do this? > > The ideal solution from the perspective of OpenVPN would be if you could > tell BIO_read (and its call tree) to do no more than N milliseconds of > work before returning with "should_retry" + some indication that the > should_retry is due to CPU timeslice exhaustion and not I/O blocking. > > So, for example, the net effect might be that BIO_read would need to be > called 16 times for 10ms each, instead of once for 160ms, where the first > 15 calls would return a should_retry status. This would nicely solve the > latency problem without introducing all the complexity associated with a > full-blown multithreaded approach. >
If you'll allow two threads then the expensive operations could be shuffled into a lower priority thread until they'd completed then moved back to the main thread. Moving the whole handshake to that thread would achieve that. That's a tricky one if you don't want any multithreading at all. You'd have to change the SSL state machine a bit adding new states for the expensive crypto operations and a new retry code. You'd also need to extend several of the APIs to be able to store their internal state periodically after only partially completing the asymmetric operations. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
