Defending against non-RCF TCP traffic

[miguelluis]

I came across the thread titled "Hung Connections" that discusses setting server session timeouts in order to clean up idle sessions. I was wondering if RCF has any built-in capability to defend against active TCP connections that continually send non-RCF traffic (or are those considered to be "idle" sessions)? We have noticed that several of our software deployments using an RCF server are accumulating TCP connections and eventually the software starts throwing the "The server has reached its incoming connection limit" exceptions. We still aren't sure what the nature of the traffic accumulating the connections is, but it may not be coming from our client software. I will be implementing the server session timeouts to see how that helps, but I'm wondering what happens if the connection is not completely idle since we don't seem to have visibility that this is taking place at the application level. If RCF does not have this capability, are there any recommended techniques to deal with it?

[jarl]

The idle timeouts should be sufficient to drop the connections you are seeing. The idle time is only reset if an actual RCF call is made, so it's unlikely that non-RCF traffic would be able to persist.