 | LIKE our fanpage 'BE YOURSELF!' |
|
Interaction of TCP/IP and Other Protocols
It is possible to classify applications as being network-aware or network-unaware. The distinction can be made because some applications, such as Web browsers and client/server applications, need to make explicit use of an underlying network protocol. Other applications, such as standard Windows application suites, simply function within the confines of a workstation's own operating system. For these applications to make use of network file and print services, it is necessary for the NOS to provide extensions to the functions of the local operating system. The next section examines how these different types of applications can make use of the underlying network. Application Programming Interface (API): Application developers can write network-aware applications by accessing a set of standard procedures and functions through an Application Programming Interface (API). This interface specifies software-defined entry points that developers can use to access the functionality of the networking protocols. The use of an API enables a developer to develop networkable applications, while being shielded from having to understand how the underlying protocols operate. Other API’s define interfaces to other system functionality.
Figure 114 provides a visual representation of how a networking API might fit within the OSI seven-layer model. The majority of network applications have been written specifically to access a single networking protocol. This is because each of the NOS implementations have developed their API’s as a standard. One of the main application requirements within a network is saving files on a central file store. To achieve this, NOS implementations commonly include a program known as a redirector. A redirector program extends the functionality of the workstation operating system to enable it to address remote file stores. In a DOS/Windows environment, file storage areas are denoted with the use of letters, typically with the letters A through E being reserved for local disk drives. When a user wants to access a network file volume, it is common for the NOS to facilitate some form of mapping between a volume name and an available drive letter. After the mapping has been made, it is possible for any application to access the shared file volumes in the same way as the would access a local drive. This is because of the operation of the installed redirector program. The program sits between the workstation operating system and the NOS protocol stack and listens for application calls made to any of the mapped network drives. The functionality of a redirector can be further clarified by considering the example of an application user attempting to save a file on a network drive. The user prompts the application to save the file on a network file volume that the NOS has mapped to the DOS drive I:. The application makes a call to the workstation operating system to complete the required file save operation. The redirector program recognise that the application is attempting to access a network drive and steps in to handle the required data transfer. If the redirector hadn't been active, the workstation operating system would have been presented with a request to save a file on a drive letter that is knew nothing about, and it would have responded with a standard error message, such as 'Invalid drive specification'. In a UNIX environment, similar file sharing capabilities are provided through the use of a Network File System (NFS). The use of NFS enables the workstation to access file volumes located on remote host machines as if they were extensions to the workstation's native filesystem. As such, the use of NFS, on the workstation side, is very similar to the use of the NOS redirector as outlined earlier. Implementation of client NFS software are available from several thirdparty companies. These implementations require a TCP/IP protocol stack to operate alongside the installed NOS protocol stack. A workstation configured with both an NOS and a TCP/IP protocol stack is able to operate two independent applications that can provide file sharing access between environments. This is accomplished through the use of the redirector program, to provide access to the NOS file server, and NFS, operating on the TCP/IP protocol stack to provide access to NFS volumes on UNIX-servers.
Figure 115 illustrates how a single workstation can be utilise to access both network environments. The indicated workstation loads a NetWare protocol software and the associated redirector software. File areas on the NetWare server are mapped as local drive F: and G:. The TCP/IP stack and NFS implementation are also loaded, and the remote UNIX file system is mounted as the local drive H: on the workstation PC. Files are then available to be saved by any application operating on the workstation to any of the mapped drivers. It is often more efficient to utilise an NOS server as a gateway into an existing TCP/IP network than to run dual protocol stacks upon each network client. In figure 117, the NetWare server has the Novel NFS Gateway software installed. The UNIX host has exported the NFS, which has been mounted to a drive on it. This file area is now available to any of the NetWare client workstations. These users are able to access the UNIX file area through the standard NetWare redirector program, removing the requirement of having to load a TCP/IP protocol stack and run a TCP/IP-based application. The NetWare server provides application gateway services between the IPX/SPX-based networks and the TCP/IP network. To achieve this, it is necessary for the server to load both protocol stacks. On the network clients, however, it is necessary to operate only the standard IPX/SPX protocol. The client directs applications requests to use resources within the UNIX network to the gateway using IPX/SPX protocols. The gateway relays these requests to the UNIX host via its TCP/IP protocol stack. In this way, the use of a gateway greatly reduces the administrative overhead required to provide network clients with access to TCP/IP hosts. Network users are able to utilise UNIX-based resources without the requirement to run multiprotocol stacks.
Figure 116 outlines a sample configuration of a NOS server as a gateway. NOS gateways tend to be implemented in one of two ways. The first is through the operation of proxy application services. The use of a proxy service provides the user with a special set of the network applications, such as Telnet, FTP, and Web browsers, that have been specifically written to operate over NOS protocols. The client applications communicate with the gateway process, which forwards the application request to the specified UNIX hosts. An alternative solution utilise a tailored version of a standard WinSock driver. This special WinSock driver provides support for standard WinSock applications, but instead of operating on an underlying TCP/IP protocol stack it communicates using IPX/SPX protocols. Yet again, communication occurs between the client workstation and the gateway application, with the gateway acting to forward application data between the client and UNIX host. The use of the tailored WinSock driver means that network clients are able to utilise any standard. WinSock application and don't have to rely on the gateway manufacturer to provide specialised application software.
Figure 117 shows a tailored version of a standard WinSock driver enables the network clients to use any standard WinSock application. The major NOS vendors have recognised an increasing demand to replace their proprietary communication methods with native TCP/IP protocols. However, network applications have generally interfaced with a specific protocol. If NOS vendors were to suddenly adopt a different protocol, many of the existing network applications would no longer function. For this reason, vendors are looking for ways to replace their proprietary network protocols, but at the same time to provide a degree of backward-compatibility to protect existing applications. For example, within NetWare it is possible to replace the standard IPX/SPX protocols with a TCP/IP protocol stack to provide standard communication between network client and server. However, within this implementation each data packet actually consists of an IPX packet enclosed within a UDP packet. The inclusion of the IPX header provides NetWare with the backward-compatibility it requires to support its existing application base. However, the inclusion of the IPX header places an additional overhead on each data packet. This overhead is likely to account for around 8 to 10 percent of the total packet size. Other NOS vendors also provide native support for TCP/IP protocols. For example, Windows NT allows for the users of the NetBEUI protocol or TCP/IP protocols or a combination of both. Within NT, network protocols are provided via an interface that it refers to as the Transport Driver Interface (TDI). This is a layer that is loaded toward the top of the protocol stack and is used to provide a standard interface between application environments and any underlying network protocols.
Figure 118 illustrates the location and operation of the Transport Driver Interface within Windows NT. At the TDI interface, standard API’s such as NetBIOS and WinSock are able to interact with communication modules, principally TCP/IP and NetBEUI. The TDI model has been designed around a flexible architecture so that it can be adapted to support additional network protocols as required. Under this networking model, applications that have been written to the NetBIOS interface can operate over an installed TCP/IP protocol stack. NetBIOS operates by assigning a unique name to every network node. The assignment and management of the NetBIOS name space results in the generation of a large amount of network traffic. This is because hosts send out broadcasts to all network nodes when they want to register the use of a name they need to perform name resolution. The NetBIOS over TCP/IP standards specifies a method whereby this functionality can occur over a TCP/IP protocol stack. The excessive broadcast requirements effectively limit the use of NetBIOS to small LAN environments where the necessary bandwidth is available. IP networks, on the other hand, often include wide area links where bandwidth might not be sufficient to handle the required broadcasts needed to maintain the NetBIOS address space.
|
