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

Websocket web-sys implementation for wasm #100

Open
lemunozm opened this issue Jun 21, 2021 · 13 comments
Open

Websocket web-sys implementation for wasm #100

lemunozm opened this issue Jun 21, 2021 · 13 comments
Labels
enhancement New feature or request

Comments

@lemunozm
Copy link
Owner

lemunozm commented Jun 21, 2021

Currently, WebSocket is working for client/server side. However, the browsers do not allow to create tcp connections direclty (which is the current implementation based). Instead, the web-sys must be used.

  • Use a different WebSocket implementation if the target is wasm.
  • wasm example of a client.
@lemunozm lemunozm added enhancement New feature or request good first issue Good for newcomers labels Jun 21, 2021
@lemunozm lemunozm changed the title Websocket web-sys implementation. Websocket web-sys implementation for wasm Jun 21, 2021
@ghost
Copy link

ghost commented Nov 18, 2021

Hi, is there news on it?

@lemunozm
Copy link
Owner Author

Hi,

Sadly, I currently don't have time to add new features to message-io, I can only make maintenance tasks

@ghost
Copy link

ghost commented Nov 18, 2021

What is mainly required to do? To have a general idea. I'm not sure if I could, but I can try to help.

@lemunozm
Copy link
Owner Author

Thanks for the help, although the solution is a little bit complex. There are two problems to tackle:

  1. The current WebSocket implementation based on tungstenite-rs do not support wasm: This, at first should be easy as creating a new adapter with a WebSocket implementation that supports it (directly o indirectly based on web-sys).
  2. (main problem) message-io uses non-blocking sockets based on mio: Currently, as a requirement, to build a new adapter you need to build it on top of mio. This should works fine for any protocol implementation based on tcp/udp. Websocket belongs to this group, but the navigators, through their API do not allow you to handle a tcp/udp socket directly, so you are forced to use WebSocket as a black box without knowledge of the underlying tcp socket that you need to register in mio. The solution here is to readapt message-io to allow making adapters that not necessarily work with mio or even using implementations that could act in a blocking way. The last one could be the "easier" and scalable solution that would allow others implementation that only works in a blocking way to be incorporated into message-io, but it requires a redesign of core parts of message-io to make it possible.

@jhg
Copy link
Contributor

jhg commented Nov 21, 2021

You're welcome. I was trying to compile message-io and I see the problem with mio. Tungstenite-rs I think is not a problem in the end. For my use case the work-around is conditional compilation for the client. And I could create a WS with web-sys and send messages to the backend that was using message-io.

About mio, I see it's not a wip the support for wasm, and even if it'll be async or sync I think it's good to abstract a bit the core from the dependency. Do yo have some idea of that redesign? I'll be not fast also because the time available, but I understand it's not urgent.

@lemunozm
Copy link
Owner Author

lemunozm commented Nov 22, 2021

I think it's good to abstract a bit the core from the dependency

Totally agree. In the first designs, I did not think about targets where mio was not supported, and wasm is clearly an example.

Do yo have some idea of that redesign?

message-io currently is pretty much tied to write/read poll concepts. The network module is split into two parts:

  • A controller (NetworkController), that makes actions and is totally independent of the poll and mio. At first, this looks ok for implementing an mio's independent adapter.
  • A processor (NetworkProcessor), that assumes that the network generates asynchronous events, waits for a poll and dispatches the event when the poll wakes up. This is the main part to change in order to support other implementations, as blocking implementations. Since message-io has the capability to offer the number of different transports the user wants to initialize, the solution here should contemplate working with blocking and non-blocking implementations at the same time and only disable the non-blocking mio's implementation if the target doesn't support it.

This is the first problem, but modifying the NetworkProcessor with a thread pool or something similar to handle each blocking connection and dispatch the network event, as usual, could work.

The second problem is how to adapt the Adapter traits to allow the user who implements an adapter to choose if they want a blocking or a non-blocking implementation. The easier solution could be to offer two kinds of adapter APIs, one for non-blocking behaviour mio based and the other for blocking usage. This implies that now we will have two drivers to handler both adapters (blocking and non-blocking) in different ways.

I think it could be possible but rewriting a big part of the library.

@markusmoenig
Copy link

markusmoenig commented May 3, 2022

Great project! Question, is there ANY Rust TCP client (or Websocket client) which could run in wasm and connect to a message-io server ?

I do not seem to find any ? Tokio etc also don't work in wasm.

@lemunozm
Copy link
Owner Author

lemunozm commented May 3, 2022

Hi Markus, thanks!

The explorers API do not expose the possibility to start TCP/UDP connections directly. If you want to connect to a server you need to do it by WebSocket using the (wasm-bindgen)[https://github.com/rustwasm/wasm-bindgen] or any other higher library that uses it. This is because the wasm applications only have access to OS utilities through the explorer API due to security reasons.

So, if you need to connect a wasm application to a message-io server you can only do it by listening to a websocket connection in the server-side.

@lemunozm
Copy link
Owner Author

lemunozm commented May 3, 2022

Regarding Websocket clients that can connect to message-io, any library that implements WebSocket using the web-sys interfaces can do the job.

A minor detail is that the message-io WebSocket adapter uses binary instead of text mode, so from a client library that want to connect to message-io, the messages should be sent as binary.

@markusmoenig
Copy link

Thanks for the answer, this helps a lot!

@lemunozm lemunozm removed the good first issue Good for newcomers label Mar 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants
@jhg @markusmoenig @lemunozm and others