Closed antmatyjajo closed 6 months ago
Unfortunately the websocket client used by this package indicates a closed connection with an empty payload. Closed connections weren't detected accurately before and this change addresses that.
Would it be possible to switch those empty binary fields to regular strings?
OK, thanks for your explanation. Sorry for my misunderstanding, but I think I am missing something fundamental - yes I can see that the client sends a close packet with an empty payload, for example after the server sends it a disconnect, but this doesn't seem to be the case with the server? I.e., the server is sending a non-empty disconnect message... Just trying to get a deeper understanding of what's going on under the hood.
Would it be possible to switch those empty binary fields to regular strings?
Yes, maybe. We have a python client but also a js client in a web app.
My example above was a bit contrived. In reality the fields containing binary content are coming from another source on the server providing binary data frames. There is a stream of results that the client is receiving as opposed to the single one in the example. The binary fields are arrays, and for a given results frame there is a possibility that one or more arrays might be empty, unfortunately that's the nature of the data.
As such it is convenient to keep the binary data as it can be very nicely directly unpacked into numpy arrays, Float32Array, ... without going through intermediate processing and conversion.
In the case of switching the binary fields to strings, it would necessitate extra data conversion steps on both my client and server sides. Maybe it would be easier for me to add some checks on my server for empty data and do something conditional on that, or change the structure of the data we are sending a bit, I'll look into it!
yes I can see that the client sends a close packet with an empty payload
That is not the issue here. The websocket client (package websocket-client
, a dependency of this Socket.IO client) has a read function that does not have a mechanism to report a connection closed. The function returns a string, and when the server responds with something unexpected (such as a close packet) this function returns a zero-length payload, instead of the something more normal such as raising an exception.
Thanks for clarifying, now I do understand the situation.
Out of curiosity would something like
if (len(p) == 0) and (not self.ws.connected):
or
if (len(p) == 0) and (self.state == 'disconnecting'):
provide a viable solution to this situation (differentiate between content that happens to be empty intentionally, and the websocket's close payload)? Or is that likely to introduce further problems?
The second suggestion would not work. The first one I'm not sure. Maybe. I'll need to test that out.
@antmatyjajo please install python-engineio from the main branch and let me know if it addresses your issue.
Can confirm that all seems good - thank you
Hi,
I have run into a problem after updating python-engineio from 4.8.x to 4.9.0. If a python-socketio
Client
receives a message with some binary attachments, and one of the binary packets happens to be empty, the client will disconnect.After some hunting around, it seems the changes made in 5b538a74061d893f255ac3544ffe1402ae97b58e are responsible, specifically the zero packet length check here.
I don't know enough about websockets/socketio/engineio to know what should be the "correct" behaviour in this case; however in my application there are binary fields in the messages sent from the server and occasionally one or more may be empty, so at least my expected behaviour (what was happening until now) is that the messages will be received in their entirety.
Thank you :)
To reproduce:
Server:
Client:
Server log:
Client log: