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:
Related C++ Sample
Related Python Sample
Related Command Line Tool
See also Trying the listAllServers Sample.
Each Wiretap server is identified by a unique a 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.
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.
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:
Related C++ Sample
Related Python Sample
Related Command Line Tool
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.
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.