And a transport deriving from asyncio.transport.Transport (a stream) might
be in fact unreliable?
I don't see any useful semantics for that.
It was more an example for why mere API (what functions with what
parameters) and implied semantics are somewhat orthogonal.
The same API (asyncio.transport.DatagramTransport) can be implemented
with different semantics (reliable vs. unreliable).
What are the exact semantics implied by Transport and DatagramTransport -
beyond the mere existence of certain functions syntactically?
You probably have to ask a more specific question.
The datagram API promises that if the sender sends two packets, and
both arrive, the receiver will see two packets, though not necessarily
in the same order (and one or both may be lost).
So my question boils down to: how can a class deriving from
DatagramTransport _programatically signal_ that it implements a more
strict set of semantics than what you say above: ordering + reliability?
"programatically signal":
One option would be by "interface identity" - but that you don't like. I
suspect you will have your reasons for that - I won't open that can;)
Another would be via (mandatory) class attributes:
DatagramTransport.is_reliable
DatagramTransport.is_ordered
An UDP implementation would have both False. WebSocket both True. I
don't know of protocols that would have mixed values.
A third option would be ReliableDatagramTransport, that
- either derives of DatagramTransport with no API change at all, merely
to signal it's more strict semantics or
- is a new class where we get rid of `addr` parameters (which are
unneeded for connected transports)
The stream API promises that the receiver sees the bytes that the
sender sent, in the same order, until the connection is terminated or
broken, but it makes no promises about whether you'll get a separate
data_received() call for each byte or a single call for all bytes. In
particular there's no promise that the framing implied by the sender's
sequence of send() or write() calls is preserved -- the network may
repackage the bytes in arbitrary blocks.
By the way, there's nothing that would prevent you from defining your
own transport and protocol ABCs.
Sure. It's all about trying to play nice and fit into the "bigger
picture". So things work together ..
