packet queue is empty, aborting EngineIO connection dropped

[N0thingLikeTheSun]

Hi,
We use an asynchronous server on the node(v 16.15.0) socket io( v 4.5.1) engine io(v 6.2.0) and a synchronous client on python(v 3.8) socket-io(v 5.5.2) engine io(4.3.2) to communicate with it.
The server sending 5 packets received from raspberry pi for analysis to the client and the client processes this data in packet synchronously,
communication is normal for some time, but after about 300 thousand packets sent to the client
receives an error "level":"LOG","message":"stderr: packet queue is empty, aborting"}. Then we need to completely restart the client, it is very disturbing and whatever changes on the part of the client in the configuration I did not test, nothing helps. Maybe there are some ideas on how to solve this?
In this case, if i use an asynchronous client, this problem does not arise, but the client performs a lot of synchronous work and change it to asynchronous will not work.
Unfortunately, I can't share the client-server code, but I can try to reproduce the problem in a simpler way than the one used in the project.

[miguelgrinberg]

The packet queue is empty when the server stops sending. I'm not really sure what can be the reason, but in the version of Socket.IO that you are using the server is supposed to send PING packets every 25 seconds by default. If the client does not see anything in more than 25 seconds it assumes the server is in a bad state and drops out.

[N0thingLikeTheSun]

Not sure, because we have 2 other asynchronous clients that receive the same information from this server, but they perform different functionality and they do not have this problem with an empty packet queue. It seems that the synchronous client does not have time to process the received information, therefore it does not accept new incoming packets. Maybe there is some special client configuration for this case?

[miguelgrinberg]

It's really hard for me to speculate without any context, but the fact that the client has time to report the error and abort suggests that it is unlikely that it does not have time to receive the pings that the server sends. Also the fact that a client uses the sync or async interfaces shouldn't change this, and if anything, async applications are more likely to block due to bugs in the application, something that is a lot less likely with threaded code.

[N0thingLikeTheSun]

Thanks for the help, now this problem does not occur, the guys from the back end made changes that fixed the packet queue, unfortunately it is not clear what exactly was done, but the problem was clearly on the server side

[MADHURRAJPUT]

Is this problem resolved, if yes could you help me how?