Skip to content
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

Add a server implementation #32

Open
1c3t3a opened this issue Mar 24, 2021 · 4 comments
Open

Add a server implementation #32

1c3t3a opened this issue Mar 24, 2021 · 4 comments
Labels
engine.io feature New feature or request socket.io All stuff related to the socket.io implementation

Comments

@1c3t3a
Copy link
Owner

1c3t3a commented Mar 24, 2021

Until now this crate only provides a socketio client. A possible server implementation could use the same packet parser and maybe parts of the engine.io socket.

@1c3t3a 1c3t3a added feature New feature or request engine.io socket.io All stuff related to the socket.io implementation labels Mar 24, 2021
@ctrlaltf24
Copy link
Collaborator

ctrlaltf24 commented Jul 16, 2021

I'm planning on implementing this. Here are some thoughts on requirements:

Requirements:

  • HTTP polling server
  • Websocket server
  • Basic async (one thread per client)
    Goals:
  • Room support
  • Secure websocket server
  • HTTPS polling server
    Stretch Goal:
  • Full async support? Change your mind on Removed all async code #17 ?
  • Full socket.io/engine.io server support

@1c3t3a Thoughts? Have anything to add or preferences on how/frameworks they are implemented in?

@1c3t3a
Copy link
Owner Author

1c3t3a commented Jul 16, 2021

Hei @nshaaban-cPacket this sounds great! I think a server implementation is definitely the most needed feature for this crate. I think the basic requirements are a full match of what I would expect, especially websocket support is important as long-polling is nearly never used anymore, but still needs support as the backup transport layer. Looking at the dependencies I would think it might be a good idea to reuse all transport related crates and not add too many new ones as this would probably bloat our build a lot. Looking at the http server, I would suggest to use rouille. I used it once and it's a pretty lightweight implementation, but feel free to use another one. I would also like to have the stretch goal of a full async support for the client and server, but I think that adding a stable version of the server with all features is enough work to keep us busy for a while. To be honest I am super happy to have a contributor helping to implement such a big feature, thanks a lot!

@ctrlaltf24
Copy link
Collaborator

Sounds good. Thank you for having a good base to start with! And with such good documentation! Did you want to continue to support sync and full async? If so there may need to be some internal organization which makes as much code as reasonably beneficial async, while still keeping sync endpoints functional without duplicating code.

@tausifcreates
Copy link

There is a rust server implementation already in development here: https://github.com/totodore/socketioxide
Please contribute with code or sponsor the guy to further accelerate the development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
engine.io feature New feature or request socket.io All stuff related to the socket.io implementation
Projects
None yet
Development

No branches or pull requests

3 participants