> I'm about to develop a server application which should be able to > handle ALOT of connections, say 20k-30k > Any suggestions as to how I should tackle this problem?
It takes a lot of experience to develop a system that can handle more than 10,000 simultaneous connections. I don't think it's realistic to expect that you'll be able to just dive into it. > I am really new with OpenSSL and haven't really grasped it all yet. > I've been searching the net for a couple of days now just to find some > threading-examples concerning OpenSSL, or the usage of select(); > > I was thinking along the lines of spawning up a couple of threads > and have a > maximum number of Connections per-thread using select to indicate when a > packet has come into the system. > What do you guys think of that? would that be possible with OpenSSL? That's a reasonable approach and will probably scale to 20,000 connections. However, 'select' is one of the worst ways to handle such a large number of connections. For example, consider a thread handling connections 18,000 through 18,200. Every time you call 'select', the kernel will have to scan through 18,000 zero bits to find the first set bit. That just doesn't seem particularly efficient. > Also I have a problem finding information on how to perform a > non-blocking > connect-negotiation. > I'm not sure how the SSL_connect() function is supposed to work, You make the socket non-blocking and call SSL_connect. If it can't complete the negotiation now because it needs to read some data, it will tell you, and you can call SSL_connect again later (possibly when you have reason to believe data is ready to be read). > I guess the > only way to go about this is using non-blocking sockets > as the SSL_connect() seems to indirectly return WANTS_READ or WANTS_WRITE > thus letting me out to the main select again (correct?) What operating system are we talking about? > but then comes to the concern of non-blocking sockets, I've heard they're > really stressfull for the system, is that true , and if so, what > would be a > sane approach to this problem? I would strongly urge you to totally ignore "X is bad" type comments. This one is especially meaningless because it's not even clear what X is. (On what operating system? Using any I/O model?) No, non-blocking sockets are generally more scalable than blocking sockets. (With 20,000 connections, are you supposed to have 20,000 threads blocked in 'read'? And then if you receive 50 packets are you supposed to switch threads 50 times?) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
