How to avoid port depletion due to non-closing sockets in a 2x reverse proxy network?

Question

I am developing a distributed reverse proxy called PortFusion . Its initial goal was to create long-term TCP tunnels with high throughput and high throughput through firewalls, especially for RDP - several, long-lived connections.

Now, in order to answer user security requirements and help activists, I am expanding them to support encryption and support many short-lived connections.

Network:

Hu 1000 <============ Cx 1000 Au [ 1001 1001=Ax:1000 ^ | | | | | | v Cu 1001 Au Hx 1000 Squid <----- 1001=Au:3128 [ 1001 <----- Firefox Legend: u you x person x A address H PortFusionHost [ hosted service C PortFusionClient < establish bidirectional link = encrypted, secure, bidirectional link - localhost-only, normal, bidirectional link Notes: - Squid as a forward HTTP proxy - Connection between two parties (===) are secure and encrypted - Cu is in complete control of what services are shared with Hx - A single Hu and a single Cu can handle multiple persons xyz 

Questions:

In the network setup above, I check the Connected socket property, for example, the one that Hx receives from Firefox @ Ax:1001 , to propagate the short circuits to the corresponding mirror sockets used by Cu to communicate with the squid.

But they always stay in touch !!

• Why do Firefox sockets always stay connected?
• Is Firefox responsible for closing the sockets that it opens for HTTP requests when it receives responses?
• Are there any other external triggers that I skip that I can sense and use to close sockets?

---

Information about the accepted answer

Using the Connected Sockets property was incorrect. Following the prompt in the accepted answer, I read this post and this MSDN article .

After the changes shown below, now both ends receive a notification as soon as the request is fully responded, and the closure propagation works just fine as expected. (There used to be another mechanism that eventually started flushing inactive sockets, but it was not fast enough.)

Code (F #) To:

  try request serverPort cl [||] while transmitting && socket.Connected do if socket.Available = 0 then Thread.Sleep Wait else let length = read() LogFlow "<:>" "Read" serverPort "<-" client length request serverPort cl <| Array.sub buffer 0 length with 

Code after:

  try request serverPort cl [||] while transmitting && read() > 0 do let length = !lengthR LogFlow "<:>" "Read" serverPort "<-" client length request serverPort cl <| Array.sub buffer 0 length with 

where read contains a Socket.Receive call and sets lengthR .

Answer 1

The connected property refers to a socket, not a connection. There is no connected state for conons. They are connected until you get EOS when reading or an error in reading or writing. What you need to distribute is an EOS condition. You do this in the proxy by disabling the output of the downstream socket. The underlying proxy product you are using should already be doing all this.

Answer 2

Many HTTP requests are executed when Keep-Alive enabled, because, as you know, it takes a considerable amount of time to establish a TCP connection. Any browser can do this, not just Firefox.

I would not be surprised to see that sockets remain open for a long time, until they close when Firefox does. They do it, right?