[New-bugs-announce] [issue47071] asyncio proactor udp transport stops responding after send to port that isn't listening

Erik Soma report at bugs.python.org
Sun Mar 20 10:58:17 EDT 2022


New submission from Erik Soma <stillusingirc at gmail.com>:

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.

----------
components: Windows, asyncio
files: udpbug2.py
messages: 415611
nosy: asvetlov, esoma, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: asyncio proactor udp transport stops responding after send to port that isn't listening
versions: Python 3.10
Added file: https://bugs.python.org/file50691/udpbug2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue47071>
_______________________________________


More information about the New-bugs-announce mailing list