tranport.get_extra_info('peername') occasionally returns None

uvloop version: 0.17.0
Python version: 3.11.4
Platform: Linux

I believe the root cause of this issue is that:

• libuv doesn't retrieve peer address while calling accept()
• getpeername() fails if the client disconnected already (which is unlikely, but possible)

Here's strace log:

561904 setsockopt(19, SOL_TCP, TCP_NODELAY, [1], 4) = 0
561904 accept4(18, NULL, NULL, SOCK_CLOEXEC|SOCK_NONBLOCK) = -1 EAGAIN (Resource temporarily unavailable)
561904 getsockname(19, {sa_family=AF_INET, sin_port=htons(32111), sin_addr=inet_addr("127.0.0.1")}, [128 => 16]) = 0
561904 getpeername(19, {sa_family=AF_INET, sin_port=htons(39898), sin_addr=inet_addr("127.0.0.1")}, [128 => 16]) = 0
561904 getpid()                         = 561904

Please note, that standard asyncio loop uses accept4() call to get the peer address:

564955 accept4(13, {sa_family=AF_INET, sin_port=htons(35516), sin_addr=inet_addr("127.0.0.1")}, [16], SOCK_CLOEXEC) = 16
564955 getsockname(16, {sa_family=AF_INET, sin_port=htons(32111), sin_addr=inet_addr("127.0.0.1")}, [128 => 16]) = 0
564955 ioctl(16, FIONBIO, [1])          = 0

Said that, there's an issue raised in libuv repo which should be addressed first, I suppose: https://github.com/libuv/libuv/issues/3339

Bắt đầu bằng cách tái hiện trường hợp uvloop 0.17.0, Python 3.11.4 trên Linux và theo dõi hành vi accept/getpeername được nêu trong báo cáo. Sau đó xem xét issue #3339 của libuv được liên kết; công việc được xem là hoàn tất khi nguyên nhân đã được xác nhận và hành vi peername đã được xác minh sau một bản sửa lỗi có thể triển khai hoặc khi đã giải quyết xong phần phụ thuộc.