The RPC server is too busy to complete this operation.

Started by
3 comments, last by taby 18 years, 1 month ago
I'm writing a stress test app for my game server, and I keep getting the following message popping up:
Quote: First-chance exception at 0x7c81eb33 in Stress Test.exe: 0x000006BB: The RPC server is too busy to complete this operation.
According to Google and the Microsoft Knowledge Base, this happens with RPC (Duh), but I'm not using it as far as I know. I am however, using sockets. I'm currently creating and connecting 20 sockets (one per thread), sending / receiving some data, then disconnecting and connecting to a new server. I can't tell where exactly this exception pops up, since when I set breakpoints in the debugger, or use OutputDebugString(), the message doesn't appear (Presumably my app runs more slowly and doesn't overload the RPC server). This isn't really a major issue, my app runs fine, but I'm still wondering what's causing it...
Advertisement
Isn't there some kind of limit on the number of server connections in Windows, unless you're using the server edition?
I hit this as well. If memory serves it is 10 concurrent connections for XP. And then if you try to hack the registry to allow more it has no effect. Our problem was fixed when we migrated the server to Windows 2003.

PS.

Try 11 connections concurrently to see if you still hit. If so, try 10 and that is probably the magic number. Hope this helps...
Thanks, I'll try that when I get home tonight. What is the limit actually on? The number of pending connections to one socket that haven't been accept()ed yet? I've had over 10,000 sockets connected to one server socket on Win2k.
From my experience, the above mentioned incoming connection limit does not cause RPC failures to occur on any Windows OS. It should simply appear to the listening socket that there are no incoming connection attempts.

10 is the maximum incoming connect limit for all workstation OSes. The server OSes have no hard-coded limit that I've ever run into using Winsock.

Perhaps wrapping the appropriate parts of the code within a try/catch block may help narrow down exactly where the exception is being thrown from? Worth a shot.

Here is a bit of info on where reasonable resource limits can be estimated from: Winsock Programmer's FAQ - Section 4: Advanced Winsock Issues

This topic is closed to new replies.

Advertisement