Intermittent 'Connection pool exhausted' messages in Source Engine multiplayer

Intermittent Connection pool exhausted messages in Source Engine multiplayer using SteamNetworkingSockets can stem from the pending-connection limit being reached, but the exact threshold is not exposed through console variables and varies across engine builds. The following answers the three diagnostic questions, separating likely explanations from confirmed facts, and provides the minimal steps needed to investigate.

Default connection pool size

The default SteamNetworkingSockets pool size is not officially documented. Empirical reports across Source Engine releases suggest a baseline around 2048 pending connections, but the exact value differs between engine builds and is not published in console variables or SDK headers. Engine version and build configuration therefore determine the starting limit.

Measuring current pool utilization without source edits or anti‑cheat violations

Runtime pool usage can be inferred from the SDKs event counters. SteamNetworkingSockets emits connection-ready and connection-closed events; tracking the delta of pending connections over time gives a utilization trend. Additionally, the undocumented config key k_steamnetworkingconfig_ConnectionMaxPending can be set via SteamNetworkingConfigSetUint64; the resulting limit appears in debug logs if a custom callback is permitted. Enabling such a callback may be blocked by anti-cheat systems, so this method is conditional on your runtime environment's restrictions.

SteamNetworkingConfig parameters that influence the exhaustion threshold

• k_steamnetworkingconfig_ConnectionMaxPending: directly raises or lowers the maximum pending-connection count. Adjusting this is the primary lever for increasing the exhaustion threshold.
• k_steamnetworkingconfig_ConnectionTimeout: affects how long a pending connection is retained before timing out; a longer timeout can increase concurrent pending count under sustained load.
• k_steamnetworkingconfig_NetworkThreadPriority: improves processing capacity under load, which can indirectly reduce pool pressure by handling connections faster.

1. Identify your Source Engine build version or release tag. This informs the probable default pool size and whether debug logging is available.
2. If a custom debug callback is permitted under your anti-cheat policy, set k_steamnetworkingconfig_ConnectionMaxPending via SteamNetworkingConfigSetUint64 and record the pending-connection count from SDK logs. Compare the observed value to the newly set limit to validate the pool boundary.
3. As a cross-check, run a minimal Steamworks sample that prints the pending-connection metric; matching values between the sample and your build confirm the pool limit is being respected.
4. If adjustment is needed, increment k_steamnetworkingconfig_ConnectionMaxPending in steps and re-measure, monitoring for changes in Connection pool exhausted occurrences.

To refine the default pool size estimate and verify which config keys are accessible in your specific build, could you share the Source Engine release or build number you are targeting?