search

WICG / direct-sockets

Direct Sockets API for the web platform
Other
362 stars 14 forks source link

Consider using streams for UDP sockets as well #17

Closed domenic closed 2 years ago

domenic commented 4 years ago

There are basically two models for programming against UDP sockets:

  1. Event style, where it's possible to tune in and out of the socket at any time, possibly missing messages
  2. Streams-with-no-backpressure, where all messages accumulate into an infinitely-growing buffer, and get processed by the consumer in order.

This spec seems to have chosen (2), since it uses async iterables (which have a built-in buffer of that sort)... but it did so without using the streams API. If (2) is indeed the desired design, then I suggest using ReadableStream / WritableStream.

FWIW, we had a similar discussion in the early days of the streams API around https://github.com/sysapps/tcp-udp-sockets, which ended up using (2).

ewilligers commented 3 years ago

We have a sequence, but there is back pressure: each send() returns a Promise. Clients can wait for the promise to resolve before sending another datagram.

The API is designed to be future compatible with one day exchanging datagrams with more that one specific peer. ReadableStream / WritableStream would likely make that more awkward.

domenic commented 3 years ago

Can you explain more about why it'd be more awkward to use streams? Async iterators seem like they'd have the same issues.

GrapeGreen commented 2 years ago

This can be closed now as we adopted streams for udp and landed the respective cl-s.