> > 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'm quite aware that that high goal is quite hard to reach, but still it's my goal. Aim for the star and you'll reach the top of trees. > 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. Yeah, I have been reading up a lot on select and poll, etc. It seems epoll is the way to go. When you say it will probably scale to 20,000 connections , do you mean because of the cpu required to process SSL or just more generally talking about select etc ? > > 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? I'm on linux. > 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?) Note taken. When I said non-blocking I was referring to setting the O_NONBLOCK flag on the socket. I was not considering giving up the idea on select. All the traffic I recieve fits into one tcp-packet, would you know if that would imply that when a packet gets into the network stack and finally ends up readable on my filedes, would the entire packet payload be immediately available on read , or is it possible that I might only get a piece of the buffer? (is that process packet->readable atomic ?) Thanks for your help/reply/information it was appreciated /Tommy Wallberg ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
