SSL thread-safety issue causes 30-55% connection failures with sync client

[MichaelRipa]

Describe the bug

The sync client (socketio.Client) experiences 30-55% connection failure rate over TLS/SSL when reconnection=False. The root cause appears to be concurrent send/recv operations on SSL sockets during the Socket.IO handshake (not thread-safe in Python).

The async client (socketio.AsyncClient) has 0% failure rate because it uses asyncio's single-threaded event loop. Similarly, none of this happens over HTTP.

I have a working fix, and will submit a PR with it.

To Reproduce

• python-socketio: 5.16.1
• python-engineio: 4.13.0
• websocket-client: 1.9.0
• Python: 3.12
• OS: Linux

import socketio
import time

URL = 'https://your-server.com' # Can provide a temporary endpoint if needed
PATH = '/socket.io'

success = fail = 0
for i in range(20):
    sio = socketio.Client(reconnection=False)
    try:
        sio.connect(URL, socketio_path=PATH, wait_timeout=10, transports=['websocket'])
        success += 1
        sio.disconnect()
    except Exception as e:
        print(f'FAIL: {e}')
        fail += 1
    time.sleep(0.1)

print(f'{fail} failures out of 20 ({fail/20*100}%)')

Expected behavior
sio.connect() should reliably establish a connection to the server when the server is reachable and functioning correctly. With reconnection=False, failures should only occur due to actual network or server issues, not internal client race conditions.

Logs

Client logs with logger=True, engineio_logger=True:

Successful connection:

2026-04-21 10:31:12,887 engineio.client INFO: Attempting WebSocket connection to wss://server/socket.io/?transport=websocket&EIO=4
2026-04-21 10:31:12,996 engineio.client INFO: WebSocket connection accepted with {'sid': 'nmw9ds1J7EPXvyQ2AAWS', ...}
2026-04-21 10:31:12,996 socketio.client INFO: Engine.IO connection established
2026-04-21 10:31:12,996 engineio.client INFO: Sending packet MESSAGE data 0{}
2026-04-21 10:31:13,012 engineio.client INFO: Received packet MESSAGE data 0{"sid":"VnbrCOaTwmteZdaWAAWT"}
2026-04-21 10:31:13,012 socketio.client INFO: Namespace / is connected

Failed connection (same server, moments later):

2026-04-21 10:31:13,862 engineio.client INFO: Attempting WebSocket connection to wss://server/socket.io/?transport=websocket&EIO=4
2026-04-21 10:31:13,976 engineio.client INFO: WebSocket connection accepted with {'sid': 'hX5STzTMxKLxzwt8AAWa', ...}
2026-04-21 10:31:13,976 socketio.client INFO: Engine.IO connection established
2026-04-21 10:31:13,977 engineio.client INFO: Sending packet MESSAGE data 0{}
2026-04-21 10:31:13,977 engineio.client WARNING: WebSocket connection was closed, aborting
2026-04-21 10:31:13,979 engineio.client INFO: Waiting for write loop task to end
2026-04-21 10:31:13,979 engineio.client INFO: Exiting write loop task
2026-04-21 10:31:13,980 socketio.client INFO: Engine.IO connection dropped

[miguelgrinberg]

I'll look into it. Don't bother sending AI generated fixes, I don't have time to review them.

[MichaelRipa]

Thanks, let me know if you run into any issues reproducing the bug

[miguelgrinberg]

I cannot reproduce with my own server.

... concurrent send/recv operations on SSL sockets ... (not thread-safe in Python).

Do you have a link to this threading issue? Note I'm not asking you/Claude to explain this to me, I just want a reference.

[MichaelRipa]

openssl/openssl#20622

[miguelgrinberg]

This issue does not appear to be specific to the connection handshake, but more of a general problem that occurs when reading and writing from SSL blocking sockets. Preventing concurrent reads and writes at all times in this library would require a major redesign of the python-engineio and python-socketio packages. And not only for the client but also for the server, which uses a similar design.

But I'm not sure this library is the right place to address this. This should be done as a lower level abstraction.

And sure enough, it seems CPython is going to address this by making the SSL sockets non-blocking (python/cpython#143756).

[MichaelRipa]

I see, thanks for looking into this. I've only experienced this issue with the initial connection, so perhaps it's worth having it just done there? But I'm happy to just patch things for my use-case and wait for the CPython changes.

[miguelgrinberg]

Well, for me it does not reproduce at all, so I can't get an idea of how big of a problem this is. This could be happening to other people at any time during the life of the connection, but because pretty much everyone has reconnects enabled it is an issue that can go unnoticed.

Considering that I don't have a good understanding of the issue and I can't even reproduce it, I can't really offer a fix. It seems the best option is to wait for CPython to address this on their side.