Page 1 of 1

OpenNetworkConnection limit

Posted: Mon Feb 10, 2020 12:24 pm
by Rjevsky
Hello! I discovered strange behavior

Code: Select all

Global count

Procedure Tcpsrv_connect(param)
   Print("connection")
  Protected ccontrol_port.l=5555
  Protected ccontrol_ip.s="192.168.101.252"
  Protected ConnectionID
    ConnectionID = OpenNetworkConnection(ccontrol_ip, ccontrol_port)
    If ConnectionID
      SendStr.s="ok"+#CRLF$
      count = count+1
      PrintN(" - "+Str(count))
      SendNetworkString(ConnectionID, SendStr, #PB_Ascii)
   ;   CloseNetworkConnection(ConnectionID)
  EndIf
EndProcedure 
InitNetwork()
OpenConsole()


While 1
  Tcpsrv_connect(1)
  Delay(20)
Wend  

With a uncommented line, the code can work almost indefinitely. But if the line is commented out and client disconnected on the server side, then the number of possible connections is limited to ~ 16300 connections. I monitored the number of connections with cports: The server correctly disconnected, but the client does not understand that the dynamic ports are already free.

update:
I looked at TCP connections on the client side with the netstat -anobq command and found only one connection on port 5555. But at the same time, I observe problems with the browser and network connections at the moment of reaching 16300 connections. Closing the client restores the normal operation of Windows.

Re: OpenNetworkConnection limit

Posted: Mon Feb 10, 2020 3:44 pm
by spikey
I'd need to access to the network library source and a protocol analyzer to give a proper answer (which I haven't got and am not expecting any time soon).
But I can think of several things that might be occurring:
1) Unclosed connections might get reused by the PB network library (I don't know if this is the case or not). What actual values do you get for ConnectionID at each iteration? If they are the same then reuse is effective. If different then it isn't.
2) 50 connections a second is a lot from a single source address. Some piece of kit between you and the server, or the server itself, might be perceiving this as a DDoS attack and dropping the packets. A symptom of this might be a connection at SYN_SENT state but never getting any further (ESTABLISHED).
3) The AV/Firewall on my machine inserts itself into the TCP/IP stack as a proxy. This will affect the normal operation of the stack and its memory requirements - but the exact implications of what this actually might be are not obvious.
4) The closed connections are in the TIME_WAIT or CLOSE_WAIT states. Connections can potentially remain in this state for an enormous amount of time in computing terms (up to 4 minutes!), during which time they will still be allocated some buffer storage.
5) I have my doubts about netstat -b, I suspect it doesn't always tell the whole truth. (I have no proof however).

The implications of all this is: there is an upper limit to the number of concurrent connections that a given hardware configuration can handle. I'd guess you've reached this point and the system can't handle any more. Knock on problems will occur in other applications accessing the network because they get denied resources too.

Basically you're DDoSing yourself. When you stop, the system recovers.

Re: OpenNetworkConnection limit

Posted: Mon Feb 10, 2020 3:50 pm
by Fred
The port number is itself limited to 65k, so indeed it's limited. Looks like in OS limit limitation anyway, there is no such limit in the PB network lib.

Re: OpenNetworkConnection limit

Posted: Mon Feb 10, 2020 9:47 pm
by Rjevsky
16300 is the approximate size of a pool of dynamic ports configured in windows.
I changed this: "netsh int ipv4 set dynamicport start=number num=range" and expanded the number of ports and the number of connections managed to greatly increase.

But I don’t understand why the client program releases resources if the client closes the connections itself and does not do it if the server part closes the connections.

I doubt that this is ddos ​​protection, because the client works if it breaks the connection itself. In addition, the increase in time between packets has no effect.

If you try to connect for a very long time, when all the ports are exhausted, you can watch how occasionally the connections skip. It seems to me that this happens when the most recent port from the dynamic pool is released. And the client does not want to start sorting through free dynamic ports first. But I don’t understand if the ports are freed anyway, why other applications cannot use them until I finish the client.