Totodore / socketioxide

A socket.io server implementation in Rust that integrates with the Tower ecosystem and the Tokio stack.

Home Page:https://docs.rs/socketioxide

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Binary packet placeholder handling does not handle all possible messages

kelnos opened this issue · comments

Describe the bug

When a socketioxide-based server receives a binary event, it only handles _placeholders in two simplistic ways:

  1. If the payload is an array, it looks for objects in that array with a _placeholder key, and counts and removes them.
  2. If the payload is an object, it looks for a _placeholder key in the root of the object, and discards the entire object if it finds it.

However, binary events can have arbitrary object structures. For example, it might look like:

{
  "id": 42,
  "body": { "_placeholder": true, "num": 0 }
}

socketioxide believes this structure contains zero binary payloads, and how the logic for processing incoming binary blobs works, this packet will never end up being complete, as a packet is only ever complete if its determined payload count is equal to the number of payloads received. (After the first binary payload is received, 0 == 1 will fail.)

To Reproduce

  1. Create a simple socketioxide server that listens for a "test" event.
  2. Using a non-socketioxide client, send a "test" event with a payload as in the above description.
  3. See that socketioxide never passes the event to its handler, and in fact never believes the packet is complete.

Expected behavior

The socketioxide server should receive the packet, understand when it is complete, and call the event handler.

Versions (please complete the following information):

  • Socketioxide version: 0.8.0 (though inspection of 0.9.x and 0.10.x show they have the same issue)
  • Http lib: warp 0.3
  • Socket.io client version: Java io.socket:socket.io-client:1.0.1

Additional context

I was going to write a bit here how the socketioxide handler API makes it ambiguous as to where the binary payloads "fit" into the data payload when we consider more complex data payload structures, but I think that warrants a separate issue, so I'll file that in a bit.