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
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()
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.
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.