You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This seems to be a macOS specific situation, and I'm not sure if it's a regression in a newer macOS or not. I've only just recently discovered this, and I'm running Sonoma, so it's definitely present in the latest macOS.
This is using luasocket as installed from luarocks
🍎 ❯ luarocks list
Rocks installed for Lua 5.3
---------------------------
luasec
1.3.2-1 (installed) - /Users/dougstephen/.luarocks/lib/luarocks/rocks-5.3
luasocket
3.1.0-1 (installed) - /Users/dougstephen/.luarocks/lib/luarocks/rocks-5.3
The repro case is pretty simple; Use socket.tcp() to create a master socket, call tcp_socket:settimeout(0), then call tcp_socket:connect(addr, port) on a known listening server socket.
Since we know the remote socket is up, we would expect the connect to succed. Instead, we receive nil, 'timeout'.
Looking at the docs, we know that we should select a socket that returns timeout after connect. But there's too much ambiguity here:
If we call connect for an address that isn't listening, we'll get timeout. A subsequent call to select with the client in the send position will return immediately with no error, but the socket isn't connected.
If we call connect for an address that is listening, we still get timeout, and the select behavior is the exact same as if the address didn't exist at all.
In other words, we can't know that the connection failed until we try to use the socket, which seems less than ideal.
I've attached a tarball with the scripts I used, and screen recordings of both macOS and Linux execution behavior for the attached scripts. Under Linux, we get the expected behavior.
The text was updated successfully, but these errors were encountered:
dljsjr
changed the title
tcp_socket:connect(addr, ip) to a listening server returns timeout if timeout is set to 0.tcp_socket:connect(addr, ip) to a listening server returns timeout if timeout is set to 0 on macOS.
May 29, 2024
This seems to be a macOS specific situation, and I'm not sure if it's a regression in a newer macOS or not. I've only just recently discovered this, and I'm running Sonoma, so it's definitely present in the latest macOS.
This is using
luasocket
as installed fromluarocks
The repro case is pretty simple; Use
socket.tcp()
to create amaster
socket, calltcp_socket:settimeout(0)
, then calltcp_socket:connect(addr, port)
on a known listening server socket.Since we know the remote socket is up, we would expect the connect to succed. Instead, we receive
nil, 'timeout'
.Looking at the docs, we know that we should
select
a socket that returns timeout after connect. But there's too much ambiguity here:connect
for an address that isn't listening, we'll gettimeout
. A subsequent call toselect
with the client in the send position will return immediately with no error, but the socket isn't connected.connect
for an address that is listening, we still gettimeout
, and the select behavior is the exact same as if the address didn't exist at all.In other words, we can't know that the connection failed until we try to use the socket, which seems less than ideal.
I've attached a tarball with the scripts I used, and screen recordings of both macOS and Linux execution behavior for the attached scripts. Under Linux, we get the expected behavior.
Attachments
The text was updated successfully, but these errors were encountered: