Client and server communication issue

---

Hi There,

I have installed one AV application on windows 2016 server(32GB & 200+GB). Which can handle and manage clients under this windows server.
As per the compatibility the application can manage 5000 endpoints from single console and currently 2000+ endpoints are only installed and reporting.

Clients will communicate to server on specified port which is 5057 and ports are allowed in firewall to accept the traffic on port 5057 from external clients.

But the issue is now most of clients are trying to communicate server on port 5057 as per the interval but at server side when ran netstat command then we used to get CLOSE_WAIT status for port 5057.
Even at server registry level we reduced TCP/IP time wait delay from 60 to 30 and increased dynamic port range. However we can see many connection are in close-waits status with TCPview utility from microsoft.
So could you please anyone help to resolve this issue at earliest. your feedback really appreciable.

Thanks,
Deepan S

@Sdeepan-Subramani said in Client and server communication issue:

But the issue is now most of clients are trying to communicate server on port 5057 as per the interval but at server side when ran netstat command then we used to get CLOSE_WAIT status for port 5057.
Even at server registry level we reduced TCP/IP time wait delay from 60 to 30 and increased dynamic port range. However we can see many connection are in close-waits status with TCPview utility from microsoft.

CLOSE_WAIT means it received 'FIN' from the other end and the program just have to close the connection locally. You may want to see if you AV program has an issue with this...it may be a programming bug that has been reported and may require an update.

Other's may want to jump in here to provide more!

Hi Ronnie

Thanks for your update to my query

So You meant to say that this issue is completely with application side right? and

RnD or product engineering team has to look into this further.

@Sdeepan-Subramani,

I'm am saying it is possible since the CLOSE_WAIT is waiting for the local application to respond to the FIN. It's not TCP that is causing that since the FIN as traversed to the server. The server is waiting for it's application to close.