Author vstinner
Recipients asvetlov, ned.deily, pablogsal, vstinner, yselivanov
Date 2018-06-07.10:21:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1528366866.19.0.592728768989.issue33694@psf.upfronthosting.co.za>
In-reply-to
Content
race.py: simple echo client and server sending packets in both directions. Pause/resume reading the client transport every 100 ms to trigger the bug.

Using ProactorEventLoop and 2000 packets of 16 KiB, I easily reproduce the bug.

So again, it's nothing related to start_tls(), start_tls() was just one way to spot the bug.

The bug is in Proactor transport: the cancellation of overlapped WSARecv() sometime drops packets. The bug occurs when CancelIoEx() fails with ERROR_NOT_FOUND which means that the I/O (WSARecv()) completed.

One solution would be to not cancel WSARecv() on pause_reading(): wait until the current WSARecv() completes, store data something but don't pass it to protocol.data_received()!, and no schedule a new WSARecv(). Once reading is resumed: call protocol.data_received() and schedule a new WSARecv().

That would be a workaround. I don't know how to really fix WSARecv() cancellation without loosing data. A good start would be to modify Overlapped.cancel() to return a boolean to notice if the overlapped I/O completed even if we just cancelled it. Currently, the corner case (CancelIoEx() fails with ERROR_NOT_FOUND) is silently ignored, and then the IOCP loop silently ignores the event of completed I/O...
History
Date User Action Args
2018-06-07 10:21:06vstinnersetrecipients: + vstinner, ned.deily, asvetlov, yselivanov, pablogsal
2018-06-07 10:21:06vstinnersetmessageid: <1528366866.19.0.592728768989.issue33694@psf.upfronthosting.co.za>
2018-06-07 10:21:06vstinnerlinkissue33694 messages
2018-06-07 10:21:05vstinnercreate