The OP and I discussed this via email and IM.

There seems to be a few issues that the OP is concerned about.  The first is that the number of allowable sockets/process is platform dependent (Windows has no limit, linux can be set manually).  The second is that some platforms limit the number of sockets that can be passed to select at a time (Windows limits this to 512, I don't know about linux).  The third is that the OP wants a solution to handling both a standard denial of service attack (single client), as well as a distributed denial of service attack (many clients).

The first issue is annoying, bit it is not within the realm of problems that should be dealt with by base asyncore.  Just like platform floating point handling is platform-dependent, sockets/file handles per process is also platform-dependent, and trying to abstract it away is not reasonable.

The second issue is also annoying, but it also isn't within the realm of problems that should be dealt with by base asyncore.  Whether or not an application should be able to handle more than a few hundred sockets at a time is dependent on the application, and modifying asyncore to make assumptions about whether an application should or should not handle that many sockets is not reasonable.

The third issue is also not reasonable for us to handle.  How to respond to many incoming connections (from a single source, or from many source) is also application dependent.  On a web server, maybe you just don't accept connections when you are overloaded.  Maybe if you follow the advice of http://www.remote.org/jochen/work/pub/zero-downtime.pdf , you handle them all.  These are all application-specific.

Now, because how to handle the cases are all platform, application, protocol, etc., dependent, assigning a single set of rules for asyncore to respond to conditions of high numbers of sockets is outside the range or problems that asyncore is intended to solve.  I would also point out that Twisted doesn't do anything special to handle these cases.  When a Twisted select reactor on linux comes to the file handle limit, it dies, just like asyncore.  When a Twisted poll reactor on linux comes to the file handle limit, it dies. On Windows, Twisted uses the Windows messaging API "WSAEventSelect and MsgWaitForMultipleObjects, or something" (http://twistedmatrix.com/pipermail/twisted-python/2006-April/012976.html), but having written a poll method for Windows using this myself, I find that select uses much less processor (I can provide you with an example).

With all of that said, since a higher-level asynchronous sockets framework doesn't handle the case that you want asyncore to handle, I can't help but say, once again, "asyncore wasn't intended to handle the situation that you describe, and how *you* handle it, as an application developer, is up to you."

Closing as won't fix.