-
-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: implement EngineIO V3 (closes #22) #24
Conversation
Marked this as draft because I still need to implement the rest for the protocol to work properly. I'm moving on with the reverse ping/pong mechanism. Feel free to check the code in the meantime though. |
Thanks for starting all of this ! I have just one suggestion, I think it is much better to have feature flags for versions (with v4,v3), and a default feature flag set on v4 and that you do all your version conditions on those feature flags. It would allow to remove useless code at compile time and also to have the information everywhere in the codebase without having a Also, don't forget to rebase from main regularly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice start, I think the feature flag solution would be better for the codebase.
I think end to end test-suites are very important, therefore if I have the time I'll try to make one for the v3 version (by copying v4) and modifing things according to changes between v3 & v4. It could be tested with the official engine.io v3 to be sure it is ok. We would then be sure that this implementation is correct |
Agreed, feature flags make more sense for this project. I'll make adjustments. |
Currently ts version has option allowEI3 and it works with both versions. |
I agree but it should be a separate feature for when eio3 is already supported. |
In the v3 protocol, characters are counted instead of using a record separator (\x1e). See: https://github.com/socketio/engine.io-protocol/tree/v3#payload
69845ae
to
eaab5e4
Compare
The V3 protocol handles transport upgrades slightly different. This commit solves an issue where the transport would be forever stuck in a polling state, even though the client thinks it has already been upgraded to websocket.
Just got started on this as well, feel free to suggest adjustments: socketio/engine.io-protocol#45 |
Sure ! I totally agree with you |
I've addressed everything now :) |
I can't comment on unchanged lines but I think you should rename this part to /// Internal channel to receive Pong [`Packets`](Packet) in the heartbeat job
/// which is running in a separate task
pong_rx: Mutex<mpsc::Receiver<()>>,
/// Channel to send Ping [`Packets`](Packet) from the connexion to the heartbeat job
/// which is running in a separate task
pub(crate) pong_tx: mpsc::Sender<()>, |
This makes the name agnositc from the protocol version that's being used.
I was a bit too fast and forgot to rename a few references, causing compiler errors. This commit fixes this.
Round 2 of the PR review : ✔️ Please let me know if more changes are required. I'd be happy to see this merged soon :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect, however the action e2e_v3 seems to fail...
I'm going to merge it and maybe we could make another PR to fix if there is still an action error
@Totodore oops socketioxide/engineioxide/src/payload.rs Line 29 in 3b802d9
there is a security issue: in case of getting the length it mustn't exceed 8 bytes. |
Right, let's fix that in another PR |
Here's some initial progress on the V3 implementation. Please provide detailed feedback if you can, I don't consider myself proficient in Rust yet.
Protocol implementation steps:
E2E tests: socketio/engine.io-protocol#45