You have not given a scrap of evidence that there is a bug in the handshake code.
On Saturday, September 19, 2015, Oleg K <windspi...@gmail.com> wrote: > in this particular case - i know why, i am doing it on purpose to emulate > what we have in real environment. > right now we have a live system written in gevent, and i am looking into > possibility of migrating it to asyncio. > (i am building test cases and benchmarks) > > it just happens, and there are many scenarios why connection may be cut in > the middle of handshake. > (including malicious ddos attempts and other sorts of weird network > issues. ) > > > > On Saturday, September 19, 2015 at 11:39:43 PM UTC-4, Guido van Rossum > wrote: >> >> You should try to figure out first why the connection is lost. Perhaps an >> error message is being logged somewhere? A possible cause could be that the >> remote end of the connection doesn't like the settings in the SSL context. >> >> On Sat, Sep 19, 2015 at 5:40 PM, Oleg K <winds...@gmail.com> wrote: >> >>> Hello, >>> >>> i have suspicion that there is a bug in ssl handshake implementation. >>> can someone tell me email or any other contact of author of that file? >>> asyncio/sslproto.py i wonder if they can help me to fix it? >>> >>> >>> to make long story short: >>> i am developing application with ssl websockets and have found a case >>> when sslproto gets into broken state. >>> >>> there is a function >>> which suppose to write into socket >>> >>> def _write_appdata(self, data): >>> self._write_backlog.append((data, 0)) >>> self._write_buffer_size += len(data) >>> self._process_write_backlog() >>> >>> >>> actually - it just populates write backlog. and later it calls: >>> >>> def _process_write_backlog(self): >>> # Try to make progress on the write backlog. >>> if self._transport is None: >>> return >>> >>> >>> which is silently exits doing nothing, because transport is *already >>> gone*. >>> and backlog keeps growing producing memory leak. no error is ever >>> raised. >>> >>> so what i found is: that it is happening when connection is just >>> established, >>> and immediately lost so lost_connection handler manages to set None to >>> self._transport. >>> >>> and whole proto just thinks it finished a handshake but same time it >>> lost the transport. >>> >>> >>> >>> >>> Regards, >>> Oleg. >>> >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> > -- --Guido van Rossum (on iPad)
