Why does it take so long to establish a connection?

Slow connection establishment can have a number of causes. A common one is that the proxy used by a client contains multiple endpoints, one or more of which are dysfunctional.

For example, a server may have multiple network interfaces. If the server does not use the -h option for its [adapter endpoint (or uses -h * or -h, the server listens on all available network interfaces for incoming requests. Moreover, in this case, the server publishes all of the endpoints in its proxies (except the loopback interface, unless the loopback interface is the only interface). As an example, if the server has network interfaces and, if you do not specify which endpoints the server should publish in its proxies, it publishes both of them.

Slow connection establishment may be encountered by the client if one of the interfaces is not accessible (for example, because a firewall disallows connecting to that interface). If the client-side run time attempts to reach the server via the inaccessible interface, it waits for the connection to be established and, only once that attempt times out, connects via the second interface. (Note that you may not see this delay on every run of the client because the Ice run time randomizes the available endpoints for connection attempts. You will see the delay only if a dysfunctional endpoint is used before a functional one.)

You can control which endpoints are published in proxies in two ways:

  • Explicitly specify the interfaces that the server's object adapter should listen on with -h. You can specify multiple endpoints, such as

    tcp -h -p 10000:tcp -h -p 10000

    if you want the server to listen at more than one (but not all) interfaces. Unless you set the property adapter-name.PublishedEndpoints, these interfaces are also published in the proxies created by the adapter.

  • You can set the property adapter-name.PublishedEndpoints to control which endpoints are published by the adapter. This works whether you use -h * or specify endpoints explicitly for the adapter: only the endpoints specified by this property are published in proxies.

Using either or both of these mechanisms, you can control exactly which interfaces are published in proxies. By leaving out interfaces that are inaccessible to clients, you avoid the slow connection establishment. (The primary use for the PublishedEndpoints property is not to avoid slow connection establishment, but to permit Ice to coexist with applications where the server is behind a NAT boundary, so proxies given to external clients require different addresses — see How do I configure my Ice server for NAT?.)

Another common cause for slow connection establishment are DNS lookups. If the server's endpoints are specified as domain names, and the DNS is not configured correctly for one or more endpoints, client-side connection establishment is delayed for each endpoint until the corresponding DNS lookup times out.

To help you debug problems with connection establishment, you can run the client with the property Ice.Trace.Network=2. This allows you to monitor each connection attempt, and the timestamps in the trace output allow you to see how long each connection attempt takes.

You can set the same property on the server side to verify on which interfaces the server listens for incoming requests: the trace includes the address of each interface the server binds to.

To find out which endpoints are embedded in a proxy, you can simply stringify the proxy with ice_toString to see its endpoint information.

See Also