UDPSocket.Close not working when NetworkInterface is set

On MacOS, calling UDPSocket.Close() after using the socket with UDPSocket.NetworkInterface set to a non-nil value, fails to reset the socket.

Subsequent attempts to Connect() will give an Error 65

The Documentation for UDPSocket says:

Close
Closes the socket’s connection, closes any connections the socket may have, and resets the socket.
The only information that is retained after calling Close is the socket’s port, address (in the case of TCPSockets), and data left in the socket’s receive buffer. All other information is discarded.

Workaround - manually setting NetworkInterface to nil before calling close seems to work.

// workaround for bug https://tracker.xojo.com/xojoinc/xojo/-/issues/78685
dim u as UDPSocket = UDPSocket1
if u.NetworkInterface <> nil then
  system.DebugLog "UDPSocket.Setting NetworkInterface to nil"
  u.NetworkInterface = nil
end if

system.DebugLog "UDPSocket.Close()"
u.close

Reported as https://tracker.xojo.com/xojoinc/xojo/-/issues/78685

1 Like

That’s a strange thing. UDP sockets are inherently connection-less so I’m not sure what “Close” would even do there.

2 Likes

Agree, UDPSockets are connectionless, but in this implementation they do bind to a specific port and can receive data in the .DataAvailable() event.

I think how it works is that
UDPSocket.Connect
gives similar features to
TCPSocket.Listen

The docs for IsConnected

For TCPSockets, a connection means you can send and receive data and are connected to a remote machine. For UDPSocket, this means that you are bound to the port and are able to send, receive, join or leave multicast groups, or set socket options.

I just don’t ever remember “closing” a UDPSocket. I think I subclassed and made close just not broadcast the events, but it’s been 15 years since.

Close should at least to unbind you from the port set. That should lead you to stop listening new data and being unable to send. The inverse of a connect()

1 Like

I remember Sequoia being plagued by error 65 reports (no route). Does this behavior occur with with older macOS versions? I ask trying to isolate where the issue is.

Not with Sonoma.

I also remember people saying that when they received a presumable false “no route”, if they waited a bit and retried, few times, for few seconds, eventually they got a success and after that things got working consistently under Sequoia. Like not less than 3 secs from the first try. And that was for new connections, TCP. Sequoia seems a PITA OS for devs and users.

I remember there being an issue on macOS where the underlying socket doesn’t get released immediately by the OS. Could that be what’s going on here?