The most difficult problem encountered when developing a network service, even impossible to solve perfectly, is that of a dealing with a stress load. Denial of service is impossible to dodge, all you can to is to keep failing gracefully and return to normal functioning when load is reduced. This feature of resilience you really want your network service to exhibit.

We therefore need the service to fail gracefully under stress load and be resilient. Although it is difficult to reason about just any network service you may build and its capabilities, let's see what Pythomnic offers.

The entry point to a Pythomnic network service is an interface, at this point the service may suffer the hit. How an interface is susceptible to stress depends on what kind of an interface it is. The supported interfaces may roughly be divided into asynchronous (message-oriented) and synchronous (web services). The examples of the former are JMS, POP3, file-based, SMPP and ICQ interfaces and the latter - HTTP, XMLRPC and SOAP.

The message-oriented interfaces are effectively single-threaded, as a single message is picked from a queue (whatever that means) and processed at a time. A heavy stream of incoming messages could at worst result in a queue overflow and message server failure, not the Pythomnic-based receiver failure. This observation is consistent with common knowledge of a message queueing server providing sort of impedance matching for its clients of different producing and consuming capabilities.

Web services being of a synchronous RPC kin are a different story. Any synchronous service is very vulnerable to a denial of service or for an occassional load peak. The reason for this is very simple - any incoming request needs processing right now, it cannot be delayed. The best strategy for dealing with an excessive stream of requests is to perform an early selective discrimination, i.e. to filter out and cancel the requests which either are known to be of malicious origin or not of critical importance. Unfortunately, such strategy is not applicable within a general request-accepting interface which the platform provides. You can indeed do such filtering in your application code, telling cancellable requests by the client IP address or by target method or its arguments, but for you to be able to to that the platform must have already had accepted and parsed the request and provided it with execution context.