We have brought this up before and it hasn’t been completely solved and I have a new idea so I’m emailing to ask.
As you know we start the Client with a Workspace json which is designed to load client and server and expt and plugin windows and Matlab/Python stuff all with one click. (Connor can testify as to how much this helps his daily work!).
We sometimes see an issue where the Client cannot find the server from the workspace file. In the workspace file, we tell it to look for the server at “localhost”.
We have a machine where this doesn’t work.
Client looks for localhost, Server is listening on 127.0.0.1 and the client can’t connect, it times out. If we set the client to look for 127.0.0.1 it works. But this is not a general solution because for other rigs, looking for 127.0.0.1 doesn’t work and we have to set the client to look for localhost.
For that reason I’m inclined to get to the root cause of why Client → localhost, Server → 127.0.0.1 is not working.
Terminal → ping localhost yields 127.0.0.1 in the ping header, so at least some resolution mechanism on the Mac is working. This is a Monterey Mac.
Do you have any idea how to test what address “localhost” is getting resolved to by MWClient? Would this be in the log somewhere?
I’m hoping that if I can figure this out we can edit /etc/hosts and be done with this for good.
In the workspace file, we tell it to look for the server at “localhost”. We have a machine where this doesn’t work. Client looks for localhost, Server is listening on 127.0.0.1 and the client can’t connect, it times out. If we set the client to look for 127.0.0.1 it works.
This jibes with my own experience with this issue. I always use “localhost” for both client and server. If the client fails to connect, telling it to use “127.0.0.1” instead fixes the problem. In one instance, the issue persisted long enough that I was able to confirm that MWClient was resolving “localhost” to the IPv6 link-local address (::1), whereas MWServer was resolving it to “127.0.0.1” (the IPv4 equivalent).
Also, it’s possible I may have fixed this while addressing a different issue. Prior to the code change in question, the client and server used different methods to resolve hostnames: The server used the OS getaddrinfo function, whereas the client let ZeroMQ handle name resolution. Post change, both client and server use getaddrinfo. Since making the change, I don’t think I’ve experienced any instances of the connection-failure issue.
This isn’t proof that it’s fixed, as the problem has only ever happened occasionally for me. However, if it does come down to a difference in the two hostname-resolution methods, then it makes sense that using the same method for both client and server would be a solution.
FYI, the code change in question has been in the nightly build since May 14, 2024.
But this is not a general solution because for other rigs, looking for 127.0.0.1 doesn’t work and we have to set the client to look for localhost.
Looking for “127.0.0.1” doesn’t work even when the server is configured to listen on “127.0.0.1”? That is not something I’ve seen, and it sounds like an unrelated issue, since no name resolution is involved. Or is the server listening on “localhost” in this case?