Hallo,
I am testing the current version 2.3.0 and in the server logs I get a lot:
WARNING Client has NOT closed socket first.
We are not using the web gui and I guess that you progammed the afrender to correctly close the socket. I have tried setting the option for SO_REUSEADDR to 1 according to https://stackoverflow.com/questions/106 ... c#10651048, but it did not help. Maybe you have another idea. I do not get the message when using "epoll". Is the epoll mode stable/better/tested ?
Thank you Sebastian
"Client has NOT closed socket first" in 2.3.0
Re: "Client has NOT closed socket first" in 2.3.0
Hi.
Here is a good description about all this:
https://github.com/CGRU/cgru/blob/maste ... ng.cpp#L18
"WARNING" just warns that client has not closed socket first in your pipeline.
It can be a problem on a huge amount of such clients.
But if you have several web browsers and may be some in-house tools, that communicates with afserver and can hold connection until afserver closes socket, it is not a problem.
You can always check whether your have a problem with it:
https://github.com/CGRU/cgru/blob/maste ... ng.cpp#L35
At work we are using EPOLL since it was implemented (2.2.3 2017.11.02). So i think that it is tested.
But "threaded&blocking" i/o is much more tested as it was from the beginning.
I think that non-blocking should be more effective on a huge amount of clients or networking with delays (not a local network). But it was not tested on such cases too.
Here is a good description about all this:
https://github.com/CGRU/cgru/blob/maste ... ng.cpp#L18
"WARNING" just warns that client has not closed socket first in your pipeline.
It can be a problem on a huge amount of such clients.
But if you have several web browsers and may be some in-house tools, that communicates with afserver and can hold connection until afserver closes socket, it is not a problem.
You can always check whether your have a problem with it:
https://github.com/CGRU/cgru/blob/maste ... ng.cpp#L35
At work we are using EPOLL since it was implemented (2.2.3 2017.11.02). So i think that it is tested.
But "threaded&blocking" i/o is much more tested as it was from the beginning.
I think that non-blocking should be more effective on a huge amount of clients or networking with delays (not a local network). But it was not tested on such cases too.
Timur Hairulin
CGRU 3.4.0, Ubuntu 24.04, MS Windows 10 (clients only).
CGRU 3.4.0, Ubuntu 24.04, MS Windows 10 (clients only).
Re: "Client has NOT closed socket first" in 2.3.0
Thank you! I will check this and report back.
Re: "Client has NOT closed socket first" in 2.3.0
Six years later, I am again seeing this a lot in our logs. It has been there in the meantime, but not so much (or I did not care, maybe 
).
I could identify this is often happening because of a call to python afnetwork.sendServer(json.dumps({"get": {"type": "jobs"}})). It seems like the size of what is returned by the server does matter a lot as I cannot trigger it with "small" requests. Does this make any sense?
).I could identify this is often happening because of a call to python afnetwork.sendServer(json.dumps({"get": {"type": "jobs"}})). It seems like the size of what is returned by the server does matter a lot as I cannot trigger it with "small" requests. Does this make any sense?