> 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 make sense. > Yeah, I have been reading up a lot on select and poll, etc. > It seems epoll is the way to go. Yes, 'epoll' is the most efficient mechanism on Linux. I recommend using level-triggered events because it's simpler. > 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 ? More generally talking about the way little mistakes can cause your process to consume absurd amounts of CPU. For example, as the number of connections goes up, how you locate a connection, how much memory you allocate per connection, and how many context switches you force all start to become significant. > 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 ?) It is absolutely not atomic. TCP is a byte-stream protocol that does not preserve message boundaries, period. That said, you can certainly *optimize* for the most common case, which will likely be an MTU of 1500 or so and as much data packed into the first receive as possible. But trust me, if you rely on it, sooner or later your code will break. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
