WireTap Self-Discovery

The WireTap protocol employs a peer-to-peer self-discovery mechanism, enabling each server to announce its presence on the network to clients. This self-configuration feature of the WireTap network is default, provided multicast messages can be broadcast and received.

Resolving Servers

Whenever a user uses Wiretap command line tools they must provide a server ID in the command. If the provided ID doesn't contain enough information to establish a connection, then WireTap uses self-discovery to determine the server ID.

When the format <ip>:<port> is used, self-discovery is bypassed as this format provides sufficient information to establish the connection. This approach is the fastest and most reliable, but it is also the least flexible one.

If you use <hostname>:<port> in place of an IP address, a name resolution will be performed via DNS. Depending on network configurations, this name resolution may take a considerable amount of time to fail, causing apparent hangs in clients.

When "IFFFS", "Backburner", or "Gateway" is used instead of a port number, or when a Storage ID is used, the client resorts to self-discovery to find the port. This includes sending a multicast discovery request and waiting for a response from the WireTap servers. Since multicast messages are inherently a best-effort mechanism, any network component may drop these messages. To speed up the process, the client retrieves the entire list from the first server that responds to the discovery request. Typically, this will be a local WireTap server due to its proximity.

Hardcoding Network Topology

In complex network setups like multi-subnet, cloud, or container environments, multicast messages may not get through. Use the file /opt/Autodesk/cfg/services.cfg to hardcode the WireTap network information.

You can populate the /opt/Autodesk/cfg/services.cfg file with the currently running servers on a given host by running /opt/Autodesk/cfg/services_snapshot.sh.