search

OrsayDev / OrsayLaser

Instrumentation for Laser / Blanker / Gain usage in Nionswift
0 stars 0 forks source link

Bad client sockets (FIN_WAIT_2 status) using netstat -an #41

Closed yvesauad closed 3 years ago

yvesauad commented 4 years ago

It is a bit hard to handle my client-side sockets. My hardwares are not always fast and thread acumulations can build up to the point that my timeout exception rises. I have put my client sockets in blocking mode while my server handles my 5 hardware (and 5 clients) using select (and hence in a non-blocking mode)

putting in blocking mode assures that my nionswift side (client) always need to receive a msg even if it is a b'None'one. I am sure i will have troubles in the future with this blocking sockets. Let's update everything in this issue thread here. This seems to be a good practice for my server health however.

Second issue is that sometimes i receive an obscure BlockingIOError: [WinError 10035] A non-blocking socket operation could not be completed immediately in my server side.

Debuggin by netstat -an shows my server with an godawful number of FIN_WAIT_2 status (or TIME_WAIT) from my previous disconnected clients. TCP handles those guys and dump them after a while (counted 200 s), so for now i put a big time.sleep between consecutive server instantiations. Very very ugly. Let's follow here if i find the solution.

kociak commented 4 years ago

It is not clear what mean by "accumulating" and "threads". If your client is non-blocking, this could be better. You just skip messages. But if the server is slow, ,i suspect this is not the prb. Making your client non-blocking should be the solution - the client thread nicely resume if there is no message to treat. However, I should read the code to have an idea (if I have one, as client-server things are always nasty ;) )