Websocket web-sys implementation for wasm

[lemunozm]

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.

[jhernandez-at-wiris]

Hi, is there news on it?

[lemunozm]

Hi,

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

[jhernandez-at-wiris]

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]

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]

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]

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]

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]

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]

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]

Thanks for the answer, this helps a lot!