Comments (10)
Thanks for the answer, this helps a lot!
from message-io.
Hi, is there news on it?
from message-io.
Hi,
Sadly, I currently don't have time to add new features to message-io
, I can only make maintenance tasks
from message-io.
What is mainly required to do? To have a general idea. I'm not sure if I could, but I can try to help.
from message-io.
Thanks for the help, although the solution is a little bit complex. There are two problems to tackle:
- 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 onweb-sys
). - (main problem)
message-io
uses non-blocking sockets based onmio
: Currently, as a requirement, to build a new adapter you need to build it on top ofmio
. 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 inmio
. The solution here is to readaptmessage-io
to allow making adapters that not necessarily work withmio
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 intomessage-io
, but it requires a redesign of core parts of message-io to make it possible.
from message-io.
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.
from message-io.
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 andmio
. At first, this looks ok for implementing anmio
'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. Sincemessage-io
has the capability to offer the number of different transports the user wants to initialize, the solution here should contemplate working withblocking
andnon-blocking
implementations at the same time and only disable thenon-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.
from message-io.
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.
from message-io.
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.
from message-io.
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.
from message-io.
Related Issues (20)
- Modify some parameters of udp connection HOT 2
- Packages contain code that will be rejected by a future version of Rust HOT 12
- Send message from basic websocket client HOT 2
- Disconnecting badly acting client (endpoint) HOT 2
- Cancelling timed messages fails sometimes HOT 3
- Release 0.14.8
- Unable to connect with FramedTcp HOT 1
- Release v0.15.0 HOT 8
- Add support for Bevy ECS HOT 3
- Error compiling with only tcp feature enabled HOT 3
- Release 0.16.0 HOT 2
- Buymeacoffee badge is misspelled ("bymeacoffee") HOT 1
- ws can not receive text HOT 10
- Is it possible to limit max packet size when using FramedTcp transport? HOT 1
- Is it possible to create an UART adapter? HOT 3
- Not compiling on linux (ubuntu 22.04) HOT 2
- Scaling of a application HOT 6
- is there any possibility for multiple thread mio eventloop? HOT 1
- Feature Request: Accept WebSocket URLs with parameters. HOT 3
- client don't try reconnect HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from message-io.