Chapter 3 - VINES Protocol Layers
The physical layer handles the transmission of a bit stream over a communication medium or channel. It activates and maintains the physical connection between the user's equipment and the physical network.
VINES supports most IEEE 802.x standards as well as the following transmission media:
Broadband Baseband Point-to-point Twisted pair Token-Ring LAN Ethernet LAN ARCNET LAN
VINES uses protocols on the data link layer to control the movement of data between nodes on the network that share physical media. The data link layer provides mechanisms for error control, flow control, and link management.
The VINES data link layer provides two functions:
Packet transfer Diagnostics packet echo between neighbors
The data link layer protocol entity is a finite-state machine. It functions within the VINES kernel in some cases. In other cases, a device driver and the communications card in the server or workstation work together to perform the protocol functions.
On the data link layer, the VINES Fragmentation Protocol (FRP) breaks up and reassembles packets as follows:
On the sending end, FRP converts packets into smaller units, or fragments, when necessary for transmission by the physical medium or data link protocol. Each fragment is contained within a frame that holds the fragment as well as the various protocol headers. On the receiving end, FRP reassembles the fragments into internet packets.
The FRP adds its own header to the packet or fragment created on the source node. This header is located between the LLC and VINES IP headers.
VINES assumes that the data link layer protocol entity provides the following services:
Sends and receives frames from neighboring nodes. Moves frames as units of data with sizes up to 1500 bytes (without data link layer protocol headers). Maximum size may change with transfer media. For example, CSMA/CD has a maximum data size of 1496 bytes with a 4-byte checksum. Broadcasts frames, except where HDLC or block asynchronous protocol entities are used.
The IEEE categorizes the data link layer into two sublayers, as shown in Figure 3-1:
Logical Link Control (LLC) sublayer Medium Access Control (MAC) sublayer
Each sublayer adds its own header to the packet, as shown in Figure 3-2. When a packet is received from the network, the protocol entities strip their header from the packet before sending it to the next higher layer.
VINES fully supports IEEE data link layer standards as implemented by many popular LAN topologies, including:
Ethernet Token-Ring ProNET ARCNET LANSTARTM OmninetTM
VINES also supports the following types of WAN topologies:
HDLC (LAPB) for synchronous point-to-point communications Block asynchronous T1 LAPD ISDN X.25
The Logical Link Control (LLC) sublayer is defined by the IEEE 802.2 LLC Logical Link Control Standard. This is the top-most sublayer within the data link layer. It supports the medium access methods specified by the MAC sublayer below it. All LLC sublayer functions are implemented by the LAN card driver.
The LLC sublayer provides two types of service:
Connectionless service - This simple service treats each frame as a separate entity. Also known as datagram service, it provides minimal frame recovery and sequencing. Connectionless service is used most often when higher layer protocols perform error recovery and sequencing.
Banyan provides this service type for VINES, TCP/IP, AppleTalk, Internetwork Packet Exchange (IPX/SPX)TM, and Remote Program Load (RPL).
Connection-oriented service - This complex service attempts to provide error-free transmission by creating a logical connection to the receiving device before transmission begins. It provides support for sequenced delivery of data and error recovery.
Banyan provides this service for its native 3270/SNA over Token-Ring LAN option.
The Medium Access Control (MAC) sublayer is the bottom-most sublayer of the data link layer. It is defined primarily by two standards, both of which are supported by VINES:
IEEE 802.3 Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method, using a bus topology. An example is Ethernet. IEEE 802.5 Token passing access method, using a star-wired ring topology. An example is the IBM Token-Ring LAN.
VINES Ethernet Implementation
The functions of the MAC sublayer as specified by Ethernet protocols (IEEE 802.3 CSMA/CD) are carried out by the Ethernet device driver and firmware on the Ethernet card. The card contains a MAC unit, which:
Encapsulates and unencapsulates frames for transmission across the cable Detects errors Implements access control algorithms
The sublayer uses an integrated tap and transceiver unit that connects to a communications card installed in the server or workstation. In VINES, the Ethernet device driver resident on the workstation or server implements the protocol functions. The firmware on the Ethernet card handles the electrical functions.
VINES and ENS servers both support native Ethernet drivers. ENS for UNIX servers support streams-based Ethernet drivers.
VINES Token-Ring Implementation
The IEEE 802.5 Token-Ring access control method involves passing a control token around a logical ring of DTEs. A DTE waiting to transmit a frame must first receive the control token. The Token-Ring communications card is connected to the physical network using a trunk coupling unit, which drives and receives signals to and from the cable. Like the Ethernet card, the Token-Ring card contains a MAC unit and protocol control firmware.
The Token-Ring device driver implements protocol functions while the firmware handles token and electrical functions. The VINES Token-Ring driver can send and receive frames containing IBM source-level routing information.
VINES workstations support native and NDIS-compliant drivers for Token-Ring cards. VINES and ENS servers both support native Token-Ring drivers. ENS for UNIX servers support streams-based Token-Ring drivers.
VINES Source-level Routing protocols (SLR) support IBM protocols used to connect workstations and servers in networks that have Token-Ring LANs connected by IBM Token-Ring bridges. VINES 5.5 and higher support both local and remote Token-Ring Bridges.
SLR protocols collect routing information in multiple Token-Ring environments, so individual nodes on separate Token-Ring LANs can establish routes to other workstations or servers. Workstations and servers in Token-Ring networks broadcast packets across all routes to determine the routing address(es) of other nodes on the network. When packets cross bridges to reach nodes on other Token-Ring LANs, the source ring and bridge numbers are added to the routing information field of the packet.
When broadcast packets reach SLR-enabled destinations, the destination workstation or server extracts the SLR information and stores it for future use along with the neighbor's information. When a message is sent back to the neighbor, the stored SLR for that neighbor is included in the Token-Ring frame. Each bridge on the path examines the SLR and uses it to send the packet to the next bridge specified in the SLR, until it reaches the neighbor destination.
Figure 3-3 shows the progression of a broadcast packet across a Token-Ring network.
Observe the following rules when planning for SLR VINES networks with Token-Ring LANs:
Workstations on Token-Ring LANs without a VINES server must have SLR enabled to communicate through bridges. If a VINES server or workstation with SLR enabled is attached to a bridge connected to other rings, all servers on those other rings must also have SLR enabled to accept and respond to SLR packets. Workstations on Token-Ring LANs with a VINES server can route traffic through the server without having SLR enabled. This increases the efficiency of the network. Workstations on Token-Ring LANs that use the NEWREV program to upgrade from any server across a bridge must have source-level routing enabled. SLR across remote bridges is supported only on servers running VINES 5.5 or greater.
Your VINES server must have SLR enabled for a Token-Ring card when the Token-Ring LAN attached to the card connects your server to an IBM Token-Ring bridge. This condition applies only if your server communicates across the bridge with other VINES servers and workstations. Otherwise, source-level routing is not needed.
Servers that act as bridges do not need SLR enabled to perform bridging functions for any of their Token-Ring cards. A server needs SLR enabled only when the server is the originator or ultimate destination of packets that contain source-level routing information.
It is recommended that you enable SLR on workstations only when a server does not reside on the Token-Ring LAN to which they are connected. When workstations and servers share the same Token-Ring LAN, you only enable SLR on the servers. The servers handle SLR for the workstations.
Enabling source-level routing on both servers and workstations on the same Token-Ring LAN does not adversely affect communications on that LAN or across LANs. However, unnecessary broadcast traffic results.
VINES workstations support native Ethernet drivers as well as Network Driver Interface Standard (NDIS) compliant drivers for Ethernet, ARCNET, and Token-Ring topologies. NDIS provides a consistent method that lets network protocols and LAN drivers communicate. Using NDIS drivers lets both VINES and non-VINES protocols use the same LAN card.
You can use any Ethernet or Token-Ring card for which the vendor provides an industry-standard NDIS MAC driver written to NDIS version 2.01.
The NDIS specification defines the interface between the LLC and MAC sublayers. VINES implements NDIS using an interface driver, for example, NDISBAN.COM. The driver provides an interface between the NDIS MAC drivers for the LAN card and VINES specific protocols.
The VINES NDIS interface driver can co-exist with NDIS interface drivers from other vendors, such as the LAN Manager NETBEUI.SYS or PC/TCP SOCKET.OS2. This lets workstations that use multiple network protocols access protocol-specific network traffic using a single LAN card.
Example Supporting Dual NDIS Interface Drivers
Figure 3-4 illustrates how VINES and other NDIS-compliant protocols share the same NDIS-compliant MAC driver on a workstation. The two sets of proprietary protocols exist in parallel stacks above the MAC driver. The MAC driver in this example, ELNKII.OS2, is for a 3Com® EtherLink® II card.
The network layer routes packets from the transport layer to a protocol service entity. VINES supports only connectionless (datagram)-based services. It uses its own and other industry standard protocols such as X.25 and industry standard IP to route messages and datagrams received from the transport layer to their destination nodes.
Generally, the network layer ensures that the datagrams and messages it passes on to the transport layer are the correct size and error free. It does not ensure that the datagrams remain in the same sequence in which they are transmitted.
The network layer protocol entities package datagrams and messages into packets which hold control or addressing information added to the fragments by the protocol entities. Packets cannot exceed 1484 bytes. The packet consists of the following segments:
IP header - 18 bytes Transport header - 16 bytes Data - 1450 bytes
For more information on the structure of these packets and the VINES IP header, see the VINES Protocol Definition.
The native VINES network layer includes the following protocols:
VINES Internet Protocol (VINES IP) Routing Update Protocol (RTP) Address Resolution Protocol (VINES ARP) Internet Control Protocol (ICP)
VINES Internet Protocol (VINES IP)
VINES IP moves packets from the IP entity at the source to the IP entity at the destination device. The destination node is specified by the VINES internet address contained in the VINES IP header.
VINES Internet Addressing
VINES addresses are logical addresses that do not contain any embedded information about the structure or topology of the physical network. This creates a virtual network in which a node can be moved from one point in the network to another without having to manually create a new address for the node.
Internet addresses are different for servers and clients on the network:
Server addresses are based on the serial number of the server. Because this serial number is stored in the server key, each server has a unique address. Workstation addresses are assigned dynamically by software using the VINES Address Resolution Protocol (ARP). The workstation's address is obtained from the workstation's routing server.
Third-party routers can implement VINES routing protocols (ARP) without supporting any VINES services. Workstations can obtain their VINES IP addresses from these routers in the same way they obtain them from VINES servers. If, however, the third-party router does not run VINES protocols, the workstation's request for an IP address is encapsulated and passed on to the nearest VINES server or router.
Macintosh workstations obtain their addresses from AppleTalk using the AppleTalk Address Resolution Protocol (AARP). See "VINES Support for AppleTalk Protocols" later in this chapter for more information.
The VINES IP header includes an destination address field which contains the destination node's internet address. The 6-byte internet address contains two fields:
The network number identifies the VINES server that assigned the address. The network number is the serial number of the server's VINES server key. The subnetwork number identifies a unique node among all the nodes assigned addresses by the server that is specified by the network number. For servers, the subnetwork number is always 0x0001 since all server network numbers are unique. For workstations, the subnetwork number is dynamically assigned, starting at 0x8000 and ending with 0xfffe.
This address may indicate the packet is one of three types:
|
|
A broadcast packet (the subnetwork number is all 1s) |
|
|
A packet destined for another network node |
|
|
A packet destined for the local node |
Each type of packet is handled differently by VINES IP. If the packet's destination address matches that of the local node, VINES IP passes it on to the protocol entity specified in the header's protocol type field. For more information on how other packet types are handled and additional fields in the packet, see the VINES Protocol Definition.
VINES Routing Update Protocol (VINES RTP)
VINES RTP distributes network topology information among servers using dynamic routing techniques. VINES servers maintain and dynamically update a routing database that details the least-cost path for routing packets and uses a routing algorithm to resolve contention between two or more identical-cost links. VINES store-and-forward routing supports dynamic load balancing of redundant equal-cost paths and automatic re-routing around communication failure points. VINES routing also uses automatic hot backup paths whenever redundant links are available between two nodes.
The protocol implementation in VINES 5.5 differs from earlier versions in that the 5.5 version provides a more controlled and reliable means of maintaining routing tables.
Sequenced RTP, introduced in VINES 5.5, makes use of sequence numbers which lets servers determine whether the routing table information they receive from neighbor servers is current. In their routing tables, neighbor servers associate sequence numbers with each other. Each time one neighbor server sends new topology information to a second, the sending server increments its sequence number by 1 and includes the updated sequence number in the RTP header of the RTP packet. When it receives the packet, the receiving server updates its routing table with the new sequence number.
Non-sequenced RTP, used in pre-5.5 releases of VINES, does not use sequence numbers to guarantee the integrity of routing table information. Instead, the non-sequenced implementation suppresses routing table updates as well as other techniques to accomplish this goal.
See the VINES Protocol Definition for more information on VINES dynamic routing.
VINES Address Resolution Protocol (VINES ARP)
VINES ARP assigns unique internet addresses to nodes that do not already have them. Once the address is assigned, ARP uses the services of VINES IP to move the packet to the destination node.
ARP has two separate protocol entities:
The address resolution service is implemented on servers and routers. It assigns VINES internet addresses to any node which has no pre-assigned address. The address resolution client is implemented on workstations (except Macintosh workstations). It broadcasts requests to the network to locate routing servers and obtain an internet address from the address resolution protocol on that server.
VINES provides two types of ARP - sequenced and non-sequenced - which support sequenced and non-sequenced RTP. For more information, see the VINES Protocol Definition.
VINES Internet Control Protocol (VINES ICP)
VINES ICP provides network layer support functions, including indications of network layer exceptions such as unknown or mismatched addresses, and special routing-cost information. See the VINES Protocol Definition for more information.
All VINES packets begin with a VINES Internet Protocol header. The header includes:
Node address A software checksum, if needed An identifier for the next protocol header in the packet The length of the entire packet
A header for another network layer protocol or transport layer protocol may appear.
Support for Non-VINES Network Layer Protocols
VINES supports other industry standard protocols on the network layer, including X.25, the DARPA Internet Protocol (IP), which is part of the TCP/IP suite of protocols, and DDP for AppleTalk. The VINES support provides routing between:
Non-VINES nodes over a VINES network VINES servers over a non-VINES network
Example Routing Non-VINES Packets Across a VINES Network
VINES uses a process called encapsulation/unencapsulation to route between non-VINES nodes:
1. VINES retains the foreign protocol headers on the message when it enters the VINES network.
2. VINES network-layer headers are added to route the message within the VINES network, if needed.
3. The VINES protocol headers are removed at the VINES gateway node that sends the message back to the foreign network.
4. The message is sent to its destination within that network.
In Figure 3-5, a message that originates on the application layer of any non-VINES node eventually arrives at a node connected to a VINES server, referred to as the VINES entry gateway. It is at the VINES entry gateway that the VINES header is added to the non-VINES packet.
Once on the VINES network (using the gateway) the message may travel through additional VINES routing servers to end up at another VINES gateway node attached to the non-VINES network. This VINES exit gateway node strips the VINES header from the packet.
The message's destination is the application layer of any non-VINES node. The node that receives it from a VINES gateway server handles any further routing within the other network.
Example Routing VINES Packets Across Non-VINES Networks
When using a non-VINES network to route VINES packets between servers:
1. VINES adds the foreign network layer headers onto the message as it leaves the VINES network.
2. The message re-enters a VINES network.
3. The foreign network headers are removed.
4. The message continues to its destination within the VINES network, as shown in Figure 3-6.
In Figure 3-6, the message originates on the application layer of any VINES node. Eventually, it arrives at a VINES server connected to the other network.
Once on the foreign network, the message may travel through additional routing servers to end up at another gateway node attached to the VINES network. This gateway node strips the VINES header from the packet. The message's destination is the application layer of any VINES node. The VINES server that receives it from the foreign network handles any further routing within the VINES network.
VINES Support for X.25 Protocols
The X.25 protocols define how to move X.25 packets over logical connections between two nodes called virtual circuits:
1. VINES IP can pass VINES IP packets to an X.25 protocol entity for inclusion in X.25 headers.
2. This lets VINES data pass through an X.25 packet-switched network.
3. When these altered packets leave the X.25 network, VINES IP removes the VINES data from them.
For more information, see the VINES Protocol Definition.
VINES Support for DARPA IP Protocols
The DARPA IP protocols move data through TCP/IP networks similarly to VINES IP:
1. The VINES packet is enclosed in a DARPA IP header.
2. The packet is sent across the TCP/IP network.
3. The DARPA IP header is stripped off when the packet is received by a VINES server.
There are two types of TCP/IP support available:
The VINES TCP/IP Routing option lets servers route IP packets through VINES networks. The VINES TCP/IP Server-to-Server option lets servers route VINES packets through IP networks.
For more information, see the VINES Protocol Definition and the Banyan TCP/IP Guide.
VINES Support for IPX Protocols
VINES servers support the IPX/SPX family of protocols. The IPX/SPX protocol stack is implemented as a loadable device driver on the server. The protocol encapsulates VINES packets in IPX headers for transmission through non-VINES networks.
ENS servers can act as TCP/IP, IPX/SPX, and VINES routers, and as local Token-Ring bridges. ENS servers also support a routing technique called tunneling. Tunneling is the process of using multiple routing protocols to move data packets through networks that support different routing protocols. When a data packet is tunneled, it is encapsulated in one or more routing protocol headers in addition to its own.
ENS servers support the following tunnels:
IPX/SPX tunnels through VINES VINES tunnels through IPX/SPX TCP/IP tunnels through VINES VINES tunnels through TCP/IP VINES tunnels through SNA AppleTalk tunnels through VINES Note: You can transmit IPX/SPX data using VINES tunnels through TCP/IP or VINES tunnels through SNA. First create the VINES tunnel through TCP/IP or SNA and then configure an IPX/SPX tunnel through VINES.
IPX Tunneling
Create VINES tunnels through IPX/SPX networks when you must connect VINES networks that are separated by IPX/SPX networks. The IPX/SPX networks can be NetWare® networks or networks connected by a router that supports IPX/SPX.
StreetTalk services on ENS servers use VINES protocols to communicate. If ENS servers are linked through routers that understand IPX/SPX protocols only, administrators must create VINES tunnels through IPX/SPX. Otherwise, the StreetTalk services on servers separated by the routers cannot communicate.
ENS supports two types of tunnels:
IPX/SPX tunnels through VINES VINES tunnels through IPX networks
For either type of tunnel, ENS supports restricted tunneling and unrestricted tunneling:
Unrestricted tunneling means that the server automatically communicates with any other server that has a tunnel configured to this server as long as the tunnel is enabled. Restricted tunneling lets you control access to your server. If the server is restricted, another server cannot communicate with your server without additional steps.
See the ENS documentation set for more information.
VINES Support for AppleTalk Protocols
At the network layer, VINES supports the following AppleTalk protocols:
The AppleTalk Address Resolution Protocol (AARP) lets a server learn LAN addresses of nodes. Using AARP packets, a server requests the LAN address from the nodes on the LAN for a particular network address and the nodes respond. For more information on AARP, see Inside AppleTalk. The Datagram Delivery Protocol (DDP) handles network traffic one level above the actual interfaces. DDP moves packets through the network. This protocol also makes routing decisions, which involve determining the appropriate paths that packets should take to reach their destinations.
When application programs, such as the VINES AFP service, send data in a AppleTalk network, they deliver the data to the underlying layers. As the data moves downward through each layer, it is encapsulated in that layer's protocol headers for delivery to the appropriate destination. By the time the application data is transmitted on the LAN, it is encapsulated in several headers. Figure 3-7 shows the encapsulation of data being sent to a Macintosh workstation.
All AppleTalk packets have this header information, whether they originate on a workstation, a server, or an AppleTalk network running through a VINES network.
When the packets reach the destination VINES server, they are delivered to the AppleTalk DDP for handling.
AppleTalk Tunneling
Headers make encapsulation, or tunneling, possible. Tunneling lets AppleTalk packets travel over a VINES network, through servers that do not run the AppleTalk protocol. To the rest of the VINES network, the encapsulated packets appear as normal VINES packets. If you use TCP/IP, you might already be familiar with this process. The TCP/IP Routing option performs similar tunneling on VINES networks.
Example Tunneling Topology
Figure 3-8 shows a network with three servers. AppleTalk ports are configured on Server USCHI001 and Server USCHI017. An AppleTalk port was not configured on Server USCHI027, which is located between the other two.
Before the AppleTalk packets leave Server USCHI001, VINES attaches VINES headers to the packets. When they arrive at Server USCHI027, they appear to be normal VINES traffic. VINES passes the packets along to Server USCHI017. The reverse is also true. Before AppleTalk packets leave Server USCHI017, VINES attaches VINES headers to the packets. When the packets arrive at Server USCHI027, they appear to be normal VINES traffic. VINES passes the packets along to Server USCHI001.
The transport layer serves as an interface between the application-oriented and network-dependent layers. It provides data transport from the source node to the destination node regardless of the physical network on which each node exists.
To do this, the transport layer supports classes of service, which provide different methods and qualities of data transmission. The transport layer protocols allow application programs to be written that run on a variety of networks.
VINES supports the following transport layer services:
Unreliable datagram service Reliable (acknowledged) message service Data stream service
Both unreliable datagrams and reliable
message are size-limited units of data that can be transmitted
from one process to another. The differences between unreliable
datagrams and reliable messages are summarized in
Table 3-1.
A data stream is a controlled flow of data between two processes. Both processes must support transmission of messages of unlimited size.
Both reliable messages and data streams support virtual connections. A virtual connection is a connection established between any two network processes. The connection acts like a two-way pipe over which data is transmitted.
VINES supports transport layer services with the following protocols:
Interprocess Control Protocol (IPC) supports unreliable datagram and reliable messaging services. Sequenced Packet Protocol (SPP) supports data stream service.
These protocols are explained in greater detail later in this chapter.
Transmission in the transport layer takes place between sockets and ports. A socket is an object that the transport layer uses to manage the flow of data between process. Sockets provide an interface between a process and the transport layer protocol entity. When a process opens a socket, the socket is bound to or associated with a message queue, called an interprocess communication port or IPC port.
Each port has a unique address that identifies the elements described in Table 3-2.
The local port number identifies either a well-known port or transient port:
A well-known port is a port address assigned by Banyan Systems to a specific application. A transient port is a port address assigned and released by system software as needed when an application opens a socket without requesting a well-known port.
Well-known and transient ports provide the same type and quality of service. Well-known ports make programming for third-party applications more convenient.
VINES IPC moves unreliable datagrams and reliable messages between transport layers on different network nodes.
IPC handles reliable messages by creating a virtual connection between the IPC protocol entities on the host and destination nodes. IPC on the destination node reassembles reliable messages that consist of multiple packets and sends them to higher level processes in a single unit. IPC acknowledges these messages and guarantees that they are placed in the port queue only once.
For more information, see the VINES Protocol Definition.
VINES SPP supports virtual connections for the transmission of data streams. An SPP virtual connection is an association between two transport layer ports anywhere in the network. In this way, the VINES transport layer handles multiple, simultaneous SPP virtual connections.
SPP guarantees that data is delivered only once and in it proper sequence. For more information on VINES SPP, see the VINES Protocol Definition.
Support for Non-VINES Transport Layer Protocols
VINES supports other transport layer protocols such as TCP and UPD through a socket interface. This interface lets you issue socket calls between processes. When you open a socket, you specify the protocol used in the transaction.
VINES Support for AppleTalk Transport Layer Protocols
At the transport layer, VINES supports the following AppleTalk protocols:
AppleTalk Echo Protocol (AEP) determines if other nodes can be reached over the network and calculates the time it takes for packets to travel to other nodes and back. AppleTalk Transaction Protocol (ATP) handles the exchange of packets between source sockets and destination sockets. Name Binding Protocol (NBP) resolves the AppleTalk names and network addresses of network entities, such as servers, file volumes, and printers. Routing Table Maintenance Protocol (RTMP) builds and updates routing tables on AppleTalk routers.
For more information, see the VINES Protocol Definition.
VINES and the Session and Presentation Layers
The VINES session and presentation layers work together to convert data to formats, such as network byte ordering, that are sent across the network. The data is converted from local procedure calls to IPC reliable messages. Both functions are handled by the VINES NetRPC® remote procedure call utility.
Overview of Remote Procedure Calls
One of the most powerful and flexible communication methods in distributed systems is the Remote Procedure Call (RPC) mechanism. An application program, called a client, makes requests to a service provider, called a service. In the source code, these requests look like ordinary local procedure calls, even though the client and service may reside on separate machines or even different networks. The local procedure call is mapped into a remote procedure call without changing the calling procedure.
NetRPC handles the entire message transmission process. All you need to do is define the specification file procedures, arguments to the procedures, and the direction of the arguments. Arguments can be either input, output, or input/output:
input arguments are sent to a service and not altered on return. output arguments are returned to the caller by the service. input/output arguments are supplied to the service, modified by the service, and returned to the caller.
The NetRPC utility compiles the specification file generating remote procedure calls from your local procedure calls. Figure 3-9 illustrates RPC transmission.
NetRPC is the VINES network compiler and remote procedure call generator. NetRPC lets you automatically generate C source code routines to pass data between your client and the service. The C source code produced when NetRPC is run can be compiled by any UNIX or DOS supported compiler.
NetRPC consists of the following components:
A specification language that defines the remote interfaces of client/service applications, including the data types of all arguments A compiler that translates a NetRPC specification into C source code A standard set of libraries for each platform supported by VINES
At the session level, NetRPC provides a network interface to the transport layer. VINES application use RPCs and IPC port addresses to exchange IPC reliable messages of up to 5800 bytes. NetRPC manages the sockets on the transport layer.
At the presentation layer, NetRPC represents and translates data types as needed. Data types are the specific format used to represent data to an application during a request-reply procedure. NetRPC transparently resolves processor-dependent issues such as byte ordering on all supported processor types.
NetRPC lets you create distributed applications and their clients. A distributed application under VINES has two parts:
The application service includes a library of functions, generated by NetRPC, that send and receive information from the client. Services can run on a server or a workstation. The application client runs under DOS, Windows, UNIX, Macintosh, or OS/2 and performs user interface functions.
With one NetRPC specification, you can set up the remote procedure interface for multiple services and clients executing on any computer supported by VINES. NetRPC automatically generates the source files needed to code both the service and its client. NetRPC lets you exchange up to 5 KB of data in each RPC. To transfer larger amounts of data, break the data up and issue several calls. These are called multi-pass RPCs.
NetRPC provides an RPC interface between a third-party service and VINES Server Service and StreetTalk Service. This lets you manage third-party services using standard VINES administrative programs.
How NetRPC Works
Both service and the client applications are defined in the NetRPC specification file. There are six basic steps to building a service that runs under VINES using NetRPC:
1. Write the specification file.
2. Compile the specification file using the NetRPC command.
3. Compile the files created by the NetRPC.
4. Archive the service object files created in step 3.
5. Use the LINT library file to begin building the service source code. Fill in the empty procedure definitions by adding general C code and the VINES functions required for the service, then define a main procedure.
6. Compile the service source code created in step 5 and link it with the service library created in step 4.
Building a client with NetRPC can be more complicated than building a service, depending on whether you use DLLs in your Windows or OS/2 clients. Follow these five steps when building a client with NetRPC:
1. Write a specification file if you have not already done so.
2. Compile the specification file using the NetRPC command.
3. Compile the object files created in step 2 as a static or dynamic link library.
4. Create the client source code.
5. Link the client application with its library.
Toolkit documentation such as the VINES Service Developer's Guide and the VINES Client Developer's Guide provide more detailed information about NetRPC capabilities, as well as how to use the utility.
Non-VINES Session and Presentation Protocols
At the session layer, VINES supports the following AppleTalk protocols:
AppleTalk Session Protocol (ASP) handles sessions between clients and services. Clients and services that are in session with each other are called session partners. ASP uses the services of the ATP protocol to move data packets between session partners. At this time, ASP is used for AppleTalk File Protocol (AFP) communication only. Apple Printer Access Protocol (PAP) lets Macintosh workstations talk with PostScript printers. Zone Information Protocol (ZIP) maps network numbers and zones in the network. A zone is a grouping of AppleTalk networks. It also services requests from AppleTalk nodes to obtain and change the mapping.
At the presentation layer, VINES supports the following protocols:
Server Message Block (SMB) protocol packages RFP requests. SMB describes the:
- Type of message
- Message format
- Return codes
AppleTalk Filing Protocol (AFP) handles file sharing. On a VINES network, AFP is implemented as a service on the server, and the VINES server functions as an AppleShare file server. (AFP runs in addition to the VINES File Services that run on the server.) Both VINES AFP and AppleShare (the service-level implementation of AFP) use the AppleTalk protocols as a base. To a Macintosh user on a VINES network, the VINES AFP service looks like an AppleShare file server.
VINES and the Application Layer
The application layer provides users with an interface to distributed applications and data that exist on the network. This is done using commands that initiate a local operating system procedure. This procedure is redirected from the operating system to the network by the VINES redirector software, as shown in Figure 3-10.
The VINES application layer provides support for VINES and third-party applications. There are three types of VINES applications or services:
Base services, such as the StreetTalk global naming service, are part of the software required to run VINES. Gateway services, such as Asynchronous Terminal Emulation (ATE), provide connectivity between VINES and other types of networks. Utility services, such as the VINES Server Service, help maintain the VINES network. Server Service is the master process on a VINES server that controls all other services.
Among the services that VINES supports are:
VINES file service VINES print service Banyan Intelligent Messaging VINES Netbios emulation VINES Named Pipe emulation VINES Tasker VINES StreetTalk VINES directory assistance service (STDA) Server Service VINES Security Service VINES Backup/Restore Service VINES DOS to UNIX/UCFS service
VINES services are described in more detail in Chapters 4 and Chapter 5.
The VINES application layer also provides support for the following types of workstations:
DOS/Windows UNIX (file sharing using the ENS for UNIX product line) OS/2 Macintosh Diskless workstations using the Remote Program Load (RPL) option
