Discovering Wiretap Servers

Understanding Server IDs

Each Wiretap server is identified by a unique server ID, used by the client application to gain access to its associated database. For example, an IFFFS Wiretap Server running on a host named montreux is discovered as montreux:IFFFS. This combination of host and database type results in unique server IDs, and is especially helpful when Wiretap servers for different Autodesk products are running on the same host.

When specifying the ID for a server already known to you, the API offers flexibility in how you construct it. You can specify the first component of the ID (host machine) by either its name or IP address. Similarly, you can specify the database type by its name such as IFFFS, Gateway, and Backburner, or by its associated TCP port.

For example, consider a host workstation named cardigan with an IP address of 192.168.1.5 that is running both an IFFFS and a Wiretap Gateway server. The following table illustrates the variety of ways you can gain access to the servers.

Wiretap Server ID Specification	Description
`cardigan:IFFFS`	The IFFFS Wiretap Server database on cardigan whose name is `IFFFS`.
`cardigan:7549`	The Wiretap server on port 7549 on cardigan. This is the default port for the IFFFS Wiretap Server. In this case, the server's database name is not needed.
`192.168.1.5:7549`	As above, using the host’s IP address instead of its name.
`cardigan:Gateway`	The Wiretap Gateway server on cardigan.
`cardigan:7183`	The Wiretap server on port 7183, the default port for the Wiretap Gateway server.
`cardigan`	The IFFFS Wiretap Server on cardigan.

These classes/methods give access to the server ID of a Wiretap server:

WireTapServerId.getId() – Returns a string containing the persistent ID of a Wiretap server.
WireTapServerInfo.getId() – The sample program listAllServers.C shows how to use this class to get the properties of Wiretap servers discovered on the network (by the WiretapServerList class). The method returns a WireTapServerId object.
WireTapServerHandle.getId() – Returns a WireTapServerId object. This method returns same as WireTapServerInfo.getId(), but is used in different contexts.

Server Handles

The WireTapServerHandle class represents a connection to a Wiretap server. It is the entry point for accessing the node hierarchy of the server. The WireTapServerHandle object is not automatically updated when there is a change on the server to which it points. For example, the storage device connected to a Wiretap server can be changed, but this change is not reflected automatically in the WireTapServerHandle object.

Wiretap Server ports

Each Wiretap server type makes use of two TCP ports. The first is for the high-bandwidth frame I/O activities, and is reserved for the exclusive use of Wiretap itself, internally. The second is reserved for the low-bandwidth data associated with metadata, and is used by your client application for all operations including traversing the node hierarchy. Different ports are used by each server type. The IFFFS, Wiretap Gateway, and Backburner wiretap servers all use different ports.

The ports are set in the Wiretap configuration associated with the Wiretap server of interest by the person responsible for installing or maintaining the servers. No configuration is required on the client side. When you know the server’s low-bandwidth TCP port, you can simply use that instead of the database name, when specifying the Server ID.

Resolving a Server ID

The first step in any workflow is locating the desired Wiretap server. To assist in this task, Wiretap is designed to automatically discover all the Wiretap servers available on the local network segment, using multicast addressing. You obtain the list of discovered servers using the WireTapServerList class. Upon instantiation of an object of this class, Wiretap silently and automatically finds one server through which it gains knowledge of all the others.

For more information on the Wiretap server list, see the FAQs:

C++	Python	Description
listChildren.C	listChildren.py	Example of listing children under a node.
listAllServers.C	listAllServers.py	Example of listing all known servers.

Tool	Description
`wiretap_server_dump`	Fetch the list of all servers.
`wiretap_network_tool`	Clean up self discovery caches.
`wiretap_multicast_listener`	Watch self discovery events.
`wiretap_get_storage_id`	Retrieve the storage ID of a server found by server ID or discovery.
`wiretap_ip_resolver`	Print IP address to which a server or storage ID resolves to.
`wiretap_resolve_storage_id`	Print the storage ID to which a server ID resolves to.
`wiretap_ping`	Check the connectivity status of a server.
`wiretap_remove_server`	Broadcast a multicast event to remove a zombie server.
`wiretap_services_snapshot`	Save state of discovery and save it to services.cfg.

Storage ID

Server Storage ID can also be used to connect to a server. The Storage ID is the persistent identifier of a storage device currently connected to the Wiretap server.

Storage ID is a preferred way of connecting since it is independent of network topology and will work, in conjunction with self discovery, after network changes. If you want users of your Wiretap client to be able to regain access to nodes from one work session to another, you must retain the storage ID. Knowing the storage ID, look for the Wiretap server connected to that storage.

C++	Python	Description
resolveStorageId.C	resolveStorageId.py	Example on how to get a `WireTapServerId` from a `Storage ID`.

Tool	Description
`wiretap_get_storage_id`	Fetch a storage ID from a server.
`wiretap_resolve_storage_id`	Resolve a storage ID to a server ID.
`wiretap_ping`	Check the connectivity status of a server.