impl AsyncRead, AsyncWrite for native MixnetClient #4634
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 2 Ignored Deployments
|
|
We can keep this one open for the other changes (AsyncWrite + Sink) as well, it will be easier to polish wholesale |
durch
changed the title
|
it's definitely not in the scope for this feature, but I wonder if conceptually it would make sense for |
| } | ||
|
|
||
| impl InputSender for Arc<ClientInput> { | ||
| impl InputSender for Arc<RwLock<ClientInput>> { |
There was a problem hiding this comment.
for sanity check, have you actually tried to run the wasm code with those changes?
imo the simplest way, without dealing with bundling et al. would be to go to wasm/client, do make build-debug-dev and finally run the internal-dev project. though I'm not 100% sure how rotten it is at this point, so you might have to make tiny changes in worker.js
| fn send_message(&self, message: InputMessage) -> Promise { | ||
| let this = Arc::clone(self); | ||
| future_to_promise(async move { | ||
| let mut this = this.write().await; |
There was a problem hiding this comment.
this limitation is a bit annoying, it means that whenever you want to send a message and waiting for the whole pipeline to go through, you can't receive anything : /
There was a problem hiding this comment.
Agree, I didn't spend a lot of time on the WASM part, I'll revisit these. One could not await on the JS level, ie use a Promise::all or something like that
| } | ||
| } | ||
|
|
||
| impl AsyncWrite for MixnetClient { |
There was a problem hiding this comment.
imo AsyncWrite shouldn't be implemented on MixnetClient directly because conceptually it doesn't make a lot of sense. you're really just sending full messages as opposed to bytes. there should be some intermediate structure, like
struct MixnetClientAsyncWrite{
recipient: Recipient
}so then you'd have something like fn async_write(&self, recipient: Recipient) -> MixnetClientAsyncWrite on the client where you could just write your bytes your heart's content without having to do any encoding
There was a problem hiding this comment.
now, for any "higher" level applications that might need AsyncRead + AsyncWrite maybe we could just make a wrapper like
struct Wrapper {
inner: MixnetClient,
// or whatever fields we need
write_recipient: Recipient,
}with maybe even Deref trait for easier use
There was a problem hiding this comment.
Thats a very good point, but I wanted to avoid adapters here, I'm gonna give it some more though, maybe with the new InputMessageCodec we can get to just sending bytes in, and they discretley get converted to messages...
Heavily inspired by what @mfahampshire did for mix-tcp, folds AsyncRead functionality into the MixnetClient.
TODO:
Interesting changes in
wasm, due toSink, we now need&mutfor sending, so had to wrap stuff inRwLockinwasmclient andmixfetchThis change is