rust-utp
rust-utp copied to clipboard
meqif
Concurrent reads and writes
Currently rust-utp doesn't allow concurrent reads and writes to the same socket. This limits its usefulness in a production context.
Ways to achieve concurrency
- Synchronize socket state access/modification and allow cloning,
- Split
UtpSocketinto reading and writing halves, and return those instead of a unified socket, - Spawn a thread inside
UtpSocketorUtpStreamto wait for incoming packets on the underlying UDP socket.
2 seems to me to be the most invasive approach, while 3 feels viscerally wrong.
I quickly built a prototype of 1 and a simple concurrent client (examples/concurrent-reads-and-writes), in the branch cloneable-socket. Then I used libutp's ucat as a server to test the client, which seemed to work reasonably well. It seems to me like a viable path.
This branch is basically what I was going to do, so thanks for that.
The only thing, theoretically, missing for me is CloneableSocket into() trait support for UtpStream.
The only thing, theoretically, missing for me is CloneableSocket into() trait support for UtpStream.
Hm, that will require either an UtpCloneableStream or creating a Socket trait.
I have a locally defined UtpStream here which is identical to yours except its into() takes a CloneableSocket. Seems to work fine here.
As it should, of course. What I'm considering is that it might be undesirable to force the user to pay the cost of using a Mutex even when one isn't needed. In that case, making UtpStream wrap around an instance of UtpCloneableStream isn't the way to go. On the other hand, having a specialized UtpCloneableStream in addition to UtpStream will duplicate code, which I'd prefer to avoid.
If we were in C++ I'd doubt if the cost of a mutex is important relative to the cost of a socket operation. But I'm not familiar enough with Rust to say if it's the same here. I don't mind if we keep our private UtpStream, I'm far more keen on fixing the deadlocked reads problem.
Some preliminary benchmarks show that UtpCloneableSocket is a bit faster than a regular UtpSocket, which is mildly surprising. I guess the mutex isn't as terrible as I expected.
