(Partial reply to some questions) 2015-01-29 12:23 GMT+01:00 Glyph <[email protected]>: > It's fine to have a different callback, say transport_connection_made(), > if you want to keep connection_made() to mean "handshake completed".
Another option is to create a cleartext socket and then switch to SSL, so you have a better control on the handshake: decide when it starts, decide how to handle SSL failure, etc. It would avoid to add any new protocol method. asyncio doesn't support this use case yet. Since it's possible to pass a socket to create_connection(), it should be possible to implement it :-) asyncio lacks a "detach" method to retrieve the socket from a transport without closing the socket. > All Twisted does for this kind of buffering is to always call > OpenSSL.SSL.Connection.send() in transport.write; OpenSSL won't send bytes > unauthenticated. There's no special logic; not even a flag we need to > honor. The new SSL implementation in asyncio is based on ssl.MemoryBIO, as the new SSL implementation in Twisted. The implementation was also designed to support STARTTLS, so you may switch from encrypted to cleartext and the opposite. I was just asking myself if we may send data in cleartext if the application is allowed too early to use the protocol. Currently, the application only gets the protocol when the handshake is done, so it cannot occur. >> For subprocess transports, we have the problem of buffering because we >> may get input data from stdout or stderr before connection_made() is >> called. BaseSubprocessTransport has a list of "pending callbacks", >> callbacks scheduled after the connection_made() method has been >> called. > > That seems strange to me. Why bother even registering any file descriptors > for reading until you've called connection_made? It's an issue of the implementation. BaseSubprocessTransport is based on connect_read_pipe() which immediatly starts reading from the pipe. Hum, by the way if the pipe gets a lot of data, the read is not paused until the subprocess transport is fully initialized. So we may buffer way too much data :-/ Modifying connect_read_pipe() to not start reading immediatly may make the code more complex, but I agree that it would be better designed :-) > You can do all of this synchronously (and Twisted does). If you want to do > it asynchronously for some reason - and I imagine there are some potentially > valid reasons - then it seems to me that it's simply the transport's > responsibility to clean up any half-initialized objects it may have created > in the process of setting up. I can't see the application being interested > in that, certainly not in the same way it would be interested in a TLS > handshake failure. Should I understand that you are against the addition of a new connection_failed() method? Victor
