That means we could not open a tcp socket connection to that address+port (“localhost: 4841”). Basically resolving that is outside of the scope of the SDK, sort of (i.e. “no one answers on the other end of the line”).

In this case it is “localhost”, thus it is the same machine. Either the server is not running, or uses different port, or the “localhost” resolved to e.g. IPv6 address when the server would only bind to IPv4 address. Typically at least on Win10 addresses tend to nowadays resolve to their IPv6 forms and some servers only bind to IPv4. Thus, could you try with an address of “127.0.0.1” instead of “localhost” to check if this was the case?

In theory we could try both versions in some future version, since we use the address which is the first resolution, sometimes there are multiple ones (meaning we might get both the IPv6 and IPv4 forms and the order depends which the OS prefers). Though this requires some investigations. Personally I would sort of argue that this is the responsibility of the OS etc. But depending how much this problem happens we might need to try both also within SDK (if possible).

One option also is to force java to use IPv4 stack always: https://stackoverflow.com/questions/11850655/how-can-i-disable-ipv6-stack-use-for-ipv4-ips-on-jre, if multiple results are received it would move the IPv4 result before IPv6, and thus we would use the IPv4 one.