[Python-ideas] PEP 3156 - Asynchronous IO Support Rebooted

[Markus]

Hi,

On Sun, Jan 6, 2013 at 10:05 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 6 Jan 2013 21:46:04 +0100
> Markus <nepenthesdev at gmail.com> wrote:
>> > By the way, how does "SSL as a protocol" deal with SNI? How does the
>> > HTTP layer tell the SSL layer which servername to indicate?

Transport.ctrl(name, **kwargs) - if the Transport lacks the queried
control, it has to ask his upper.

In case of chains like TCP / SSL / HTTP, SSL can query the hostname
from it's Transport - or HTTP can query

>> > Or, on the server-side, how would the SSL layer invoke the HTTP layer's
>> > servername callback?

Transport.ctrl(name, **kwargs)

HTTP can query for the name, in case of TCP / SSL / HTTP, SSL may
provide an answer.

> Right, these are the C OpenSSL APIs. My question was about the
> Python protocol / transport level. How can they be exposed?

Attributes of the Transport(-side of a Protocol in case of stacking),
which can be queried.
For TCP e.g. it would be handy to store connection-related things in a
defined data structure which keeps domain, resolved addresses, and
used-address for current connection together.
like TCP.{local,remote}.{address,addresses,domain,port}

For a client, SSL can query for "TCP.remote.domain" and in case it is
not an ip address - use for SNI.
For a server, HTTP can query SSL.server_name_indication.

> An internal buffering mechanism in a protocol can avoid making many
> copies and concatenations (e.g. by using a list or a deque to buffer the
> incoming chunks). The transport cannot, since the Protocol API mandates
> that data_received() be called with a bytes object representing the
> available data.

bytes-like would be much better then for the definition of data_received.
same semantics, but a list of memoryviews with offset, whatever is
required internally.


MfG
Markus