You'd write this
yield from asyncio.wait_for(socket.read_handshake(), <timeout_in_seconds>)
Thanks! That's handy ..
I'm not entirely sure what Twisted endpoints are and why they're so
My understanding: they completely decouple the creation of application
specific factories/protocols from the creation of network
clients/servers using the former and created from "client/server string
descriptors".
Clients/servers can be created from string descriptors. This allows to
write programs that let users determine on command line whether to use
eg TCP, Unix domain socket or even Serial.
cool. (Glyph kept telling me they were cool but not quite ready or
something, so I never had a good look.) But most of what you describe
here should be possible equally well with asyncio's protocol/transport
abstractions (which are pretty close to those in Twisted, if you
aren't too attached to Deferred). So what's missing?(Probably nothing
that couldn't be added on top of asyncio as a 3rd party package.)
What's missing is probably something like this (which I guess could be
added to asyncio):
coro = loop.create_server(EchoServer, stream_server_descriptor)
where
stream_server_descriptor = "tcp:127.0.0.1:8000"
or
stream_server_descriptor = "unix:/tmp/myserver"
A concrete question: what APIs are missing in asyncio's datagram
transport and protocol classes to support SCTP and WebSocket? (Apart
DatagramProtocol.datagram_received and DatagramTransport.sendto take an
`addr` parameter.
However, SCTP and WebSocket are _connected_ protocols.
Hence, there isn't anything missing actually, but `addr` is in excess.
So for sendto, the addr would either needed to be ignored, or raised
when non-None.
And for datagram_received, the addr would either be the fixed addr of
the connected peer, or be set None.
As a corollary: how is addr handled with connected UDP?
FWIW: https://twistedmatrix.com/documents/current/core/howto/udp.html#auto3
Finally: yes, syntactically, there is nothing which would distinguish an
ordered, reliable datagram interface from and unordered, unreliable
datagram interface (at least a connected one).
Mmh, but shouldn't the interface _identity_ also express semantics?
If I get a transport, and want to adjust behavior according to whether
the transport is unreliable, even today I am not supposed to do that
via isinstance(transport, DatagramTransport), since DatagramTransport
doesn't imply any semantics, but only specifies a programmatic interface
(on a syntactical level)?
And a transport deriving from asyncio.transport.Transport (a stream)
might be in fact unreliable?
What are the exact semantics implied by Transport and DatagramTransport
- beyond the mere existence of certain functions syntactically?
Cheers,
/Tobias
