This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author esoma
Recipients asvetlov, esoma, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware
Date 2022-03-20.14:58:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1647788297.71.0.92757207379.issue47071@roundup.psfhosted.org>
In-reply-to
Content
Reproducer attached. Change `USE_PROACTOR` to `False` to use the `SelectorEventLoop` instead, which doesn't exhibit this behavior.

The output on my machine when using the proactor loop is:
```
datagram received b'ping 1'
datagram received b'ping 2'
```

And the selector loop (which is the behavior I would expect):
```
datagram received b'ping 1'
datagram received b'ping 2'
datagram received b'ping 3'
```


At a high level, after sending data to an address that isn't listening the asyncio protocol will no longer receive messages.


Digging deeper, `_ProactorDatagramTransport._loop_reading` encounters the windows error 1234 (ERROR_PORT_UNREACHABLE) after the "bad send". It appears this a (undocumented/buggy?) behavior of `WSARecvFrom` where the next call to it after an unreachable `WSASendTo` in UDP mode will return the ICMP unreachable message. The actual error is returned from `GetOverlappedResult`.


I've hacked together a fix that retries `IocpProactor.recvfrom` if the result is ERROR_PORT_UNREACHABLE. It fixes the issue for the reproducer and my actual use case, but it's probably not ideal. My solution for the moment is just to use the SelectorEventLoop instead.
History
Date User Action Args
2022-03-20 14:58:17esomasetrecipients: + esoma, paul.moore, tim.golden, asvetlov, zach.ware, yselivanov, steve.dower
2022-03-20 14:58:17esomasetmessageid: <1647788297.71.0.92757207379.issue47071@roundup.psfhosted.org>
2022-03-20 14:58:17esomalinkissue47071 messages
2022-03-20 14:58:17esomacreate