Chapter 8 - VINES Protocol Support for Applications
VINES protocols support both Banyan and third-party applications. These applications communicate through the underlying transport, session, and presentation layer protocols, which are described in Chapter 6 and Chapter 7.
Table 8-1 lists the Banyan applications that use VINES protocols to communicate, and the immediate underlying protocols - both VINES and non-VINES - that they use.
The sections that follow provide examples of how VINES applications use VINES protocols to communicate:
Accessing a File Service from a DOS Workstation
After logging into the network, a DOS workstation user accesses a file service, fsapps@eng@development, on a VINES 5.5 server as follows:
1. When the user logs in to the network, the user's profile issues this command:
setdrive h fsapps@eng@development
2. The setdrive client is loaded from the user's VINES Files Service into the DOS workstation over an SPP connection. This connection links the DOS workstation redirector and the VINES Files service.
3. The setdrive client uses NetRPC to communicate with a StreetTalk Service. The client requests the service to return the port address of fsapps@eng@development.
4. Upon receiving the port address, the SETDRIVE client requests the workstation redirector to map the letter h to the requested file service.
5. When the user performs the first operation on the file service, such as a DOS DIR command, the redirector establishes an SPP connection to the file service with the port address.
Accessing a PC Network Printer from a DOS Workstation
After logging in to the network, a DOS workstation user can access a PC network printer through a print service, ps@eng@development, on a VINES 5.5 server as follows:
1. When the user logs in to the network, the user's profile invokes the following command:
setprint lpt1 on ps@eng@development
2. The SETPRINT client is loaded from the user's VINES Files Service into the DOS workstation over an SPP connection. This connection links the DOS workstation redirector and the VINES Files Service.
3. The SETPRINT client uses NetRPC to communicate with a StreetTalk Service. The client asks the service to return the port address of ps@eng@development.
4. Upon receiving the port address, the SETPRINT client asks the workstation redirector to map lpt1 to the requested print service.
5. When the user submits a print job to the print service, the workstation redirector sends data to the print service with NetRPC. The redirector supplies the port address that was returned by the SETPRINT command.
6. The print job is queued on a disk on the server where the print service runs.
7. The print service sends the data over an SPP connection to the PCPRINT client that runs on the DOS workstation where the PC network printer is connected.
Connecting to VINES Files from a DOS Workstation
Once a DOS workstation has received a VINES internet address and its routing tables are built, the redirector is ready to map drive letter Z to the special file service, VINES Files@servername@Servers. This file service contains VINES client programs and associated files, such as the SETDRIVE and SETPRINT clients.
Drive Z can be mapped to any VINES Files Service that matches the software version of the user's VINES workstation software. With the logical mapping of drive Z to VINES Files, VINES Files is not tied to a particular server location.
The redirector establishes the VINES Files session before user login. To establish a session with VINES Files, the redirector performs the following algorithm:
1. The redirector issues an unreliable IPC VnsFindSvc broadcast with a hop count of 0 (zero) and a well-known port of 0x0006. This broadcast just travels to all neighbor servers using the VINES Files well-known port. The broadcast messages contain information on the VINES version that the redirector is looking for.
2. If a neighbor server with the appropriate version responds, the redirector establishes an SPP connection with that VINES Files Service.
If more than one neighbor server has the appropriate version, the redirector chooses the first one that responds. Typically, the first responding server has the fastest processor, or the server with the lightest processing load.
3. If no neighbor server with the appropriate version responds, the redirector issues another VnsFindSvc broadcast with a hop count of 1, allowing the broadcast to travel to all servers one hop beyond the local medium.
The broadcast travels over LANs only. The server router for the LAN where the workstation resides filters VINES Files broadcasts so that they do not travel over serial lines or other WAN connections.
4. If a server with the appropriate version responds, the redirector establishes an SPP connection with that VINES Files Service.
If more than one server has the appropriate version, the redirector chooses the first one that responds. Typically, the factors that determine which server responds the fastest depend on the relative processor speeds of the servers and the amount of network traffic between the servers and the workstation.
5. If a server with the appropriate version does not respond, the redirector notifies the user that an appropriate VINES Files version could not be found.
Propagating StreetTalk Information
The StreetTalk naming service is a distributed database. Each VINES, ENS for UNIX, and ENS server has a StreetTalk Service that cooperates with other StreetTalk Services to maintain the StreetTalk database. Each service maintains a portion of the complete name database. The services communicate with each other to manage global naming.
StreetTalk groups are the fundamental unit of distribution. A group is maintained by a particular StreetTalk Service, which maintains all item names and their associated attributes within the group. Any StreetTalk Service in the network can maintain a group. When adding a group, the administrator specifies the server where the group will reside. When a group is added to or deleted from the network, the StreetTalk Service on the server that maintains the group uses unreliable IPC to broadcast news of the change to its neighbors. See Chapter 6 for more information on unreliable IPC.
Servers broadcast to neighbors only. When neighbor servers that act as routers receive broadcast datagrams indicating a group has been added or deleted, they broadcast news on LANs or WANs other than ones where they received the broadcast. In turn, routers on these LANs and WANs continue the propagation, and so on. In effect, routers act as StreetTalk filters, propagating only necessary information and discarding the rest.
StreetTalk uses zero-hop broadcasts to propagate information. Each StreetTalk Service that receives the broadcast decides whether or not to propagate it. The StreetTalk Service bases its decision on the following factors:
![]()
Whether it is a router ![]()
Whether it has already propagated the information
This feature suppresses propagation when circular routes exist in the network.
Since third-party routers do not support the StreetTalk Service, they are unable to propagate StreetTalk information, and must act as a transparent bridge when they deal with these StreetTalk broadcast packets. These packets are identified as follows:
![]()
The destination VINES network ID in the VINES IP header is the VINES broadcast address. This address consists of all 0xFs. ![]()
The VINES destination port in the IPC short header specifies the StreetTalk well-known port of 0x000F. ![]()
The VINES source subnetwork ID in the VINES IP header indicates a server (subnetwork ID of 0x0001).
Whenever a third-party router receives StreetTalk broadcast packets, it must follow these rules:
![]()
Do not decrement the hop count. ![]()
Check whether the packet was received on the interface that provides the best path to the originator of the packet. The originator is identified by the source VINES internet address in the VINES IP header: - If the packet was received on the interface that provides the best path, forward the packet on all other attached interfaces.
- If the packet was not received on the interface that provides the best path, the packet has looped back and should be discarded.
The Time Service is an invisible service that runs on every server. Invisible services cannot be viewed through utilities such as OPERATE and MNET.
The Time Service propagates time information in the same way that StreetTalk propagates group information:
![]()
With zero-hop broadcasts ![]()
With the help of other Time Services running on neighboring VINES, ENS for UNIX, and ENS servers that are responsible for propagating and filtering the broadcast
The Time Service also uses two-hop broadcasts to set or change the current network time.
Third-party routers have to deal with propagation of time information in the same way that they have to deal with propagation of StreetTalk information. The routers must act as transparent bridges for the Time Service broadcast packets, which are identified as follows:
![]()
The destination VINES network ID in the VINES IP header is the VINES broadcast address. This address consists of all 0xFs. ![]()
The VINES destination port in the IPC short header specifies the Time Service well-known port of 0x0007. ![]()
The VINES source subnetwork ID in the VINES IP header indicates a server (subnetwork ID of 0x0001).
Whenever a router receives one of these packets, it must follow the same rules that it follows for handling StreetTalk propagation. See "Propagating StreetTalk Information" earlier in this chapter for more information.