ephemoral port exhaustion on Windows at least

[michaelhunley]

I am running into situations where running Ruflo MCP in Claude is triggering a lot of short lived connections, which then exhausts the ephemoral port supply and other processes (and requests for claude work with conenctions) is blocked. I Am seeting this on my PC (Win 11). I have not run into this on my MAc, but I am also not trying to run agent processes on my mac doing the continuous port interaction to another local process like I am on PC. Anyone run into this and have a solve? Does RuFlo support more permanent connections instead of firing up many short lived?

[starkmarkus]

This does sound like ephemeral port exhaustion / too many connections stuck in TIME_WAIT, especially if it only happens on Windows and Ruflo is creating many short-lived local connections.

I would first verify it from Windows while the problem is happening:

netstat -ano | findstr TIME_WAIT
netstat -ano | findstr 127.0.0.1

or:

Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending

If you see a very large number of short-lived connections to the same local port/process, then the issue is probably not Claude itself, but the transport pattern between Claude/Ruflo/local MCP processes.

The real fix would be connection reuse or a long-lived transport. For an MCP server, I would expect stdio or a persistent HTTP/SSE-style connection to be much safer than opening many short-lived TCP connections for tool calls.

So the things I would check are:

• whether Ruflo is running as stdio MCP or HTTP MCP
• whether there is an option to keep connections alive / reuse a client
• whether each tool call creates a new local process or new TCP connection
• whether Claude is configured to spawn Ruflo repeatedly instead of keeping one server process alive
• whether the local service Ruflo talks to supports keep-alive

As a workaround, you can reduce concurrency/rate of tool calls if Ruflo exposes such a setting, or restart the local MCP/server process when the port table gets saturated. Windows TCP tuning may help a bit, but I would treat that as a workaround, not the main fix.

So my question for Ruflo maintainers would be: does Ruflo currently reuse a persistent connection for MCP/tool traffic, or does it create short-lived local TCP connections per operation? If it is the latter, a keep-alive/persistent transport option would probably be the right fix for Windows.