Open spumer opened 4 years ago
You're actually talking about multiple issues.
UDPTransport
should raise errors if used after connection_lost()
is called.UDPTransport.sendto(DATA, (IP, 0))
would silently close the transport.local_addr=("192.168.0.2", 0)
?My answers:
connection_lost()
is called. However uvloop can be more user-friendly to raise errors if UDPTransport
is used after connection_lost()
as asyncio does (even though asyncio's error is not friendly enough). On the other hand, it's also worth checking why connection_lost()
is triggered and if that's necessary.connection_lost()
is called, you should listen to that event. However, asyncio won't close the transport on Linux - this is something to double-check. Not reproduced on macOS.socket.socket(socket.AF_INET, socket.SOCK_DGRAM).bind(('127.0.0.1', 0))
.I'm not sure about your quote of the RFC or your Sentry report, but I guess you were saying we shouldn't allow local_addr=("192.168.0.2", 0)?
No, RFC references for UDPTransport.sendto(DATA, (IP, 0)) would silently close the transport.
Sentry screenshot just proof for "i'm really got request with zero src port"
my2c
A UDP sender SHOULD NOT use a source port value of zero.
A UDP receiver SHOULD NOT bind to zero.
suggests that who writes the software should not bind that port. Such framework should not prevent users from shooting themselves in the foot
PYTHONASYNCIODEBUG
in env?: Yesuvloop silently closes UDP socket when sending data to incorrect destination.
Test program:
asyncio output:
uvloop output:
Then we can cut off first block with sending to None destination. And here we have NEW ONE differece in handling ip:port.
When i run it with asyncio event loop all looks fine, socket still present.
When i run it with uvloop it silently closes, and also i can go into infinity wait on
recv()
callAs i know RFC describe that case as (https://tools.ietf.org/html/rfc8085#section-5.1):
But i got real messages from the internet with that port. I will drop it in my application, but i think uvloop should not silently closes socket. It's very unexpected and differ from asyncio event loop.
Proof from Sentry (https://github.com/spumer/source-query-proxy):
next iteration of recv packet was failed, cause in previous we send response to zero port