feat(socketioxide/v4): implement SocketIO V4 (closes #51)

[sleeyax]

Protocol implementation steps:

• Add implicit connection to the default namespace
• rename CONNECT_ERROR to ERROR Not necessary because the value hasn't changed, only the name.
• The CONNECT packet shouldn't contain a payload
• The payload CONNECT_ERROR should be a plain string instead of an object. I might skip implementing this, I think a v4 client currently would receive a JSON string as the error, which isn't a big deal.
• Add E2E tests (WIP: https://github.com/sleeyax/socket.io-protocol/tree/v4-testsuite)

[sleeyax]

I'm having a hard time figuring out an annoying issue with tests. Sometimes the tests fail and sometimes they don't 🤔

It's likely related to this part of the implementation:

Add implicit connection to the default namespace

I'm not sure how tests should behave when the client is already connected to the default namespace when the connection is made. Maybe I'm encountering a race condition? Or perhaps my server implementation is just wrong. Either way, I would appreciate it if someone with some time to spare could have a look and help me out, I need to take a break from this :)

Example to reproduce

Server:

cargo run --bin socketioxide-e2e --all-features

Client:

npm test -- -f "should allow connection to a custom namespace"

    // ...
    it("should allow connection to a custom namespace", async () => {
      for (let i = 0; i < 3; i++) {
        console.log(i); // works at i = 0, fails at i = 1

        const socket = new WebSocket(
          `${WS_URL}/socket.io/?EIO=3&transport=websocket`
        );
  
        await waitFor(socket, "message"); // Engine.IO handshake

        socket.send("40/custom");
  
        const { data } = await waitFor(socket, "message");
  
        expect(data).to.startsWith("40/custom");
      }
    });

[sleeyax]

Hey all, just wanted to mention that I'm currently busy with other projects. I'm not sure when I'll be able to get back to this PR. If anyone wants to take over, definitely don't wait for me. Cheers!

[Totodore]

I'm having a hard time figuring out an annoying issue with tests. Sometimes the tests fail and sometimes they don't 🤔

It's likely related to this part of the implementation:

Add implicit connection to the default namespace

I'm not sure how tests should behave when the client is already connected to the default namespace when the connection is made. Maybe I'm encountering a race condition? Or perhaps my server implementation is just wrong. Either way, I would appreciate it if someone with some time to spare could have a look and help me out, I need to take a break from this :)

Example to reproduce

Server:

cargo run --bin socketioxide-e2e --all-features

Client:

npm test -- -f "should allow connection to a custom namespace"

    // ...
    it("should allow connection to a custom namespace", async () => {
      for (let i = 0; i < 3; i++) {
        console.log(i); // works at i = 0, fails at i = 1

        const socket = new WebSocket(
          `${WS_URL}/socket.io/?EIO=3&transport=websocket`
        );
  
        await waitFor(socket, "message"); // Engine.IO handshake

        socket.send("40/custom");
  
        const { data } = await waitFor(socket, "message");
  
        expect(data).to.startsWith("40/custom");
      }
    });

A bit late but it corresponds to this issue : socketio/socket.io-protocol#32

[tausifcreates]

Is it necessary to support a legacy protocol?

[Totodore]

Is it necessary to support a legacy protocol?

@sleeyax made 90% of the work, it is not a big deal to merge this PR

[sleeyax]

Is it necessary to support a legacy protocol?

I personally needed this to support a legacy socketio client that pretty much can't upgrade to the latest protocol version any time soon. I'm sure others will have similar use cases in the future for socketioxide and given you can leverage Rust feature flags I don't see a reason not to support older protocols. And finally, like totodore said most of the work for V4 is done already anyways :)

[tausifcreates]

Is it necessary to support a legacy protocol?

I personally needed this to support a legacy socketio client that pretty much can't upgrade

Makes perfect sense, thanks for explaining @sleeyax

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.