The architecture we saw last time is actually a nice solution to the original web service problem.  We did end up changing the security mechanism, transfer mode, message arrangement, and transport policy through a couple of different configurations in this series, but all of those individual changes are easy to do with WCF transports.  The final solution is actually quite similar to the originally proposed architecture.  However, the hardest part is not configuring WCF but knowing what mitigation steps to take for the specific problem you see with your service.  A big goal I have with this blog is to disseminate this knowledge out to the world from the team here at Microsoft.

Even with chunking in place, when the number of concurrent users hitting the service starts increasing, we might still get a lot of dropped or incomplete connections.  Fortunately, this probably isn't an architecture problem but rather more of the built-in Denial of Service protections we have in WCF.  When the server starts quickly dropping connections even though plenty of resources are available, three settings to look at are ListenBacklog, MaxPendingAccepts, and MaxInboundConnections.

ListenBacklog limits the number of prospective connections that the server can have pending.  When ListenBacklog is too low, we will stop servicing new connections until the server acknowledges some of the existing connections.  This setting is right on the frontline preventing simple DOS attacks caused by flooding the server with lots of new connections.

MaxPendingAccepts limits the number of channels that the server can have waiting on a listener.  When MaxPendingAccepts is too low, there will be a small interval of time in which all of the waiting channels have started servicing connections, but no new channels have begun listening.  A connection can arrive during this interval and will fail because nothing is waiting for it on the server.

MaxInboundConnections limits the number of incoming connections that the server can be handling simultaneously.  When MaxInboundConnections is too low, the server is not able to receive a new request until other requests have finished.  If this condition persists for too long, the request will fail because the server didn't complete receiving it in time.  Note that we sometimes expose this setting through MaxConnections instead of MaxInboundConnections.

I have a post coming up in a few weeks that clarifies this issue and goes into detail about all of the transport settings.

Next time: The Old Indigo ABC's