Comment by Ericson2314
3 days ago
What will the socket API look like for multiple streams? I guess it is implied it is the same as multiple connections, with caching behind the scenes.
I would hope for something more explicit, where you get a connection object and then open streams from it, but I guess that is fine for now.
https://github.com/microsoft/msquic/discussions/4257 ah but look at this --- unless this is an extension, the server side can also create new streams, once a connection is established. The client creating new "connections" (actually streams) cannot abstract over this. Something fundamentally new is needed.
My guess is recvmsg to get a new file descriptor for new stream.
I would look at SCTP socket API it supports multistreaming.
SCTP is very telecom-shaped; in particular, IIRC, the number of streams is fixed at the start of the connection, so (this sucks but also) GP’s problem does not appear.
That problem doesn't appear, but also trying to pass off a stream as a readable/writable thing to a polymorphic interface ("everything is file") wouldn't work.
...however sctp_peeloff (see other thread) fixes the issue. Hurray!
API RFC is https://datatracker.ietf.org/doc/html/draft-lxin-quic-socket...
Ah fuck, it still has a stream_id notion
How are socket APIs always such garbage....
2 replies →
> API RFC is ...
still a draft though.
I checked that out and....yuck!
- Send specifies which stream by ordinal number? (Can't have different parts of a concurrent app independently open new streams)
- Receive doesn't specify which stream at all?!