Hi, !

We are not using HttpClient. Currently, we have no plans on moving the drive product to .net core.

Please describe your case.

What does "issues" mean?
What files do you have under the drive directory, how are they changing?
Please send logs from the product to support and mention this thread on the forum.

Thank you!

The issue is our server cannot communicate to the AD controller because the CloudBerryDriveHost.exe uses all available connections/ports.
netstat -b shows CLOSE_WAIT on all ports

Is there a way to control the maximum number of connections/ports CloudBerryDriveHost.exe can use?
Maybe we can tweak the Windows Registry for TCPIP for MaxUserPort and TcpTimedWaitDelay.

Please advise if this is feasable:
- shorten up the time connections "wait" before Windows really, really closes them. To do this, add the following HEX/DWORD entry to the local registry of your client system. By default, the implicit value is "120", which means a time out of 2 minutes. You can pick a value of TcpTimedWaitDelay down to "1", but a higher value is recommended.
HKEY_LM\System\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay = 30 (decimal)
- other TCPP parameters to tweak
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\
DisableIPSourceRouting = 2 (protects against packet spoofing)
EnableDeadGWDetect = 0 (disable; to avoid certain DOS attacks)
EnableICMPRedirect = 0 (disable; to avoid certain routing attacks)
KeepAliveTime = 300000 (5 minutes; implicit default is 1 hour)
TcpMaxDataRetransmissions = 4 (implicit default is 5)

Hello ,

shorten up the time connections "wait" before Windows really, really closes them. To do this, add the following HEX/DWORD entry to the local registry of your client system. By default, the implicit value is "120", which means a time out of 2 minutes. You can pick a value of TcpTimedWaitDelay down to "1", but a higher value is recommended.
HKEY_LM\System\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay = 30 (decimal)

I'm not sure that this affects CLOSE_WAIT, because the official Microsoft documentation says that the TcpTimedWaitDelay value determines the length of time that a connection stays in the TIME_WAIT state when being closed! But let's give it a try!

Could you please send us diagnostic information from that machine? Please click onto the tray icon, select Diagnostics, fill the form and past a link to that conversation.

Will follow up with ticket#253322