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.

classification
Title: asyncio.create_unix_server has an off-by-one error concerning the backlog parameter
Type: behavior Stage:
Components: asyncio Versions: Python 3.11, Python 3.10, Python 3.9, Python 3.8, Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: asvetlov, jnsnow, yselivanov
Priority: normal Keywords: patch

Created on 2022-02-10 21:24 by jnsnow, last changed 2022-04-11 14:59 by admin.

Files
File name Uploaded Description Edit
issue.patch jnsnow, 2022-02-10 21:24
Messages (1)
msg413025 - (view) Author: John Snow (jnsnow) Date: 2022-02-10 21:24
Hi, asyncio.create_unix_server appears to treat the "backlog" parameter as where 0 means that *no connection will ever possibly be pending*, which (at the very least for UNIX sockets on my machine) is untrue.

Consider a (non-asyncio) server:

```python
import os, socket, sys, time

sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind('test.sock')

sock.listen(backlog=0)

while True:
    print('.', end='', file=sys.stderr)
    time.sleep(1)
```

This server never calls accept(), and uses a backlog of zero. However, a client can actually still successfully call connect against such a server:

```python
import os, socket, time

sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.setblocking(False)

sock.connect('test.sock')
print("Connected!")
```

When run against the server example, the first invocation of this client will actually connect successfully (Surprising, but that's how the C syscalls work too, so... alright) but the second invocation of this client will raise BlockingIOError (EAGAIN).

Further, if we amend the first server example to actually call accept(), it will succeed when the first client connects -- demonstrating that the actual total queue length here was actually effectively 1, not 0.

(i.e. there's always room for at least one connection to be considered, and the backlog counts everybody else.)

However, in asyncio.BaseSelectorEventLoop._accept_connection(...), the code uses `for _ in range(backlog)` to determine the maximum number of accept calls to make. When backlog is set to zero, this means we will *never* call accept, even when there are pending connections.

Note that when backlog=1, this actually allows for *two* pending connections before clients are rejected, but this loop will only fire once. This behavior is surprising, because backlog==0 means we'll accept no clients, but backlog==1 means we will allow for two to enqueue before accepting both. There is seemingly no way with asyncio to actually specify "Exactly one pending connection".

I think this loop should be amended to reflect the actual truth of the backlog parameter, and it should iterate over `backlog + 1`. This does necessitate a change to `Lib/test/test_asyncio/test_selector_events.py` which believes that backlog=100 means that accept() should be called 100 times (instead of 101.)

A (very) simple fix is attached here; if it seems sound, I can spin a real PR on GitHub.
History
Date User Action Args
2022-04-11 14:59:56adminsetgithub: 90871
2022-02-10 21:24:35jnsnowcreate