Application Programming Interface

The API is a set of C++ classes that provides access to ATM network services to applications that require ATM signaling. The API uses three different modules to achieve its functionality. First, it uses a lower-level CODEC library to encode and decode ITU and ATM Forum specified information elements and messages. Second, it uses the ipc libarary to communicate over a Unix Domain socket connection for a signaling session with the SD. Third, it uses the driver interface to bind the (vpi,vci) pair identifiying an ATM connection to a file descriptor so that data can be sent and received on that connection. These three modules are well-isolated, using a base interface that delegates to actual implementations. For example, the driver interface supports the FORE Systems implementation of the xti interface on Solaris platforms, as well as an IOCTL-based interface to a local driver on SunOS 4.3.1. Similarly, one can easily adapt a different IPC mechanism for the signaling session between the application and the signaling daemon. The SEAN API implements an object-oriented interface to non-blocking functions for creating native ATM applications. The API is based on the call-back model. Each call-back function is atomic. That is, it is not interrupted by any event even if one of its own actions caused that event. The SEAN API separates an application program from the ATM signaling services that it requires. It hides the signaling mechanisms from the application. It alerts the application to a change in a call, service, or leaf through a collection of call-back functions. Client and server applications communicate with a signaling Daemon (SD). They tell the SD when they want to establish or tear down a call, register or de-register a service, or join or drop a leaf. The SD performs all of the ATM signaling and informs them when a call, leaf, or service becomes active or inactive. In addition, the SD informs them when there is data for a call to read. All of this happens asynchronously and atomically through call-backs. There is also a way for applications to schedule periodic self-events inside applications, and this does not require the services of an SD.

Figure 2.4: API interaction with the live signaling daemon (SD)

Figure 2.5: API interaction with the simulated signaling daemon (SimSwitch)