feat: uid-mux

[sinui0]

This PR moves/reimplements uid-mux in this repo.

Changes

• Uses newer version of yamux which has better flow control. This should give us higher throughput.
• Stream ids are now hashed to a fixed-length
• Better logging
• Cleaner.

[sinui0]

This is supporting work to implement a multi-threaded executor in mpz

[sinui0]

Sigh, hold off on review. There is a deadlock somewhere

[sinui0]

It is seeming to me that yamux may have a bug, hard to say conclusively. It looks like their implementation is letting data sit in the write buffer with no way to flush it.

[sinui0]

Nope, nevermind there is a way to flush it. Fix coming soon

[sinui0]

@th4s @themighty1 ready!

[themighty1]

gw!!
Some comments, potentially blocking.

Also, could you pls adjust the comments acc.to the style guide to be /// Create --> Creates etc.
I'll open a PR to add the guide to this repo.

[th4s]

Very nice and clean 🚀

There is one thing I do not get. There has to be some future running in order to transmit the data between client and server on existing streams. But currently it looks to me that in YamuxFuture::poll in the end we return Poll::Pending. So there has to be some way to wake it again, so that again data is transmitted.

But the only place we wake it, is when opening a stream (and when closing the connection). This to me sounds like data on existing streams is only transmitted when a new stream is opened or the connection is closed.

So what I mean is that yamux::Connection::poll_next_inbound is not permanently polled.

EDIT: After some more investigation, I now suspect that it works correctly, because yamux::Connection::Active contains a loop in its poll method.

[sinui0]

@th4s

But the only place we wake it, is when opening a stream (and when closing the connection)

Anytime a Future returns Poll::Pending it (should) clone the Waker provided by Context and ensure that it is triggered when it is ready to be polled again. All the polls of the underlying yamux connection are doing this, so they contribute to driving YamuxFuture in addition to YamuxCtrl

[sinui0]

@th4s @themighty1 it seems my understanding of Waker was not complete. Apparently it is re-usable across multiple Future:poll calls and does not need to be cloned multiple times. This is nice and simplifies things a bit.

Edit: Nevermind, ChatGPT lied to me! 😂

Note that on multiple calls to poll, only the Waker from the Context passed to the most recent call should be scheduled to receive a wakeup.

[themighty1]

There is a race condition iiuc which violates this requirement: "Note that on multiple calls to poll, only the Waker from the Context passed to the most recent call should be scheduled to receive a wakeup"

Suppose that the future has just been polled and the execution is somewhere around this line

tlsn-utils/uid-mux/src/yamux.rs

Lines 309 to 310 in e2b207c

	fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
	match self.role {

If around the same time the YamuxCtrl::close() call happens and tries to get the waker in

tlsn-utils/uid-mux/src/yamux.rs

Line 345 in e2b207c

.map(|waker| waker.wake_by_ref());

it will get the waker from the previous context, not from the current context as per the requirement.

[sinui0]

That would be fine, as the future would already be getting polled. What matters is that the waker is reset before the future returns Poll::Pending, which it does on every poll. The risk of waking a stale waker is that the future never gets polled again and you get a deadlock.

[themighty1]

ack