• No results found

Extensions to the Original Implementations

In document dtj v01 03 sep1986 pdf (Page 85-89)

The initial implementations of the LAT protocol were on the terminal servers described above and on VAX/VMS host systems . The servers i m p l e m e n t e d o n l y t h e m a s t e r e n d of t h e LAT protocol , whereas the hosts implemented the s l ave end . Fo l l ow-on i m p l e m entations have added s i m i l a r s u p po r t for a d d i t i o n a l host systems: t h e MicroVMS , RSX- 1 1 M - PLUS , MicroRSX, ULTRIX-3 2 , ULTRIX-3 2m, TOPS- 1 0 , and TOPS-2 0 systems.

Each system implementation offers access to the command interpreter as the service access point. Figure 5 illustrates this support.

U L T R I X-32 TOPS-20

SYSTEM SYSTEM MicroVMS MicroRSX TOPS- 1 0

SYSTEM SYSTEM DECserver 1 00 . . . T E R M I NALS SYSTEM ETH E R N ET T E R M I N A L S E R V E R T E R M I NALS DIAL-IN MODEMS

Figure 5 Additional LA T Host Support

84 Digital Tecbnicaljournal

VAX/VMS HOST DECserver 1 00 TERMINALS NON-LAT HOSTS ETHERNET TERMINAL SERVER

TERMINALS DIAL-IN PERSONAL MODEMS COMPUTERS

Figure 6 Ethernet Configured as a Service Node

Version 2_0 of the Ethernet Terminal Server, released in August 1985, added the reverse-IAT implementation, permitting a server to offer additional services to which terminal users can connect_ This imple mentation permits sessions to be created within the box as well as across the network, thus forming a switch style of operation in a single server. The types of services that may be offered by the terminal server can be grouped into the following three categories.

The first category is connections to non-IAT hosts. In this mode, the server acts as the Ether­ net connection for systems (typically not made by Digital) that cannot themselves offer IAT ser­ vices on the Ethernet. Asynchronous ASCII ports on these systems are connected to a terminal server. Terminal users on the same or different terminal servers can connect to the service offered. They can then communicate with the non-IAT host as though it were connected to the Ethernet.

The second category is service for dial-out modems. Terminal users can connect to a port in a pool of dial-out modems. The users can then use the appropriate ASCII protocol to create a dialed connection and then access the remote system via its own dial-in port.

Digital Techntcaljournal No. 3 September 1986

The third category is serv

i

ce for personal com- puters (PC). They can be c

b

I nnected to terminal servers and run in either of the terminal emula- tion modes. Each PC thus acts as though it were a dumb terminal. A PC can 'also run in file trans­ fer mode when connected to another PC via .the same, or another, terminal server. Figure 6 illus­ trates the terminal server as a service node.

Subsequent versions of the Ethernet Ter­ minal Server, the DECserver 1 0 0, and the VMS

LTDRIVER software all permit asynchronous printers to connect to terlninat servers. These versions also allow print qu¢ues to be directed to the printers from hosts. The IAT protocol has been enhanced so that th

connection mecha­ nism remains under the c

ti

j. ntrol of the terminal server (for the reasons of efficiency mentioned previously). That enhancement allows a host to "solicit" a connection from a port on a terminal server. Once the connection has been made, data transfer can occur as in the normal interactive terminal case, except that the printer output is under the direction of a VMS print symbiont. It is possible, with these implementations, to direct the queues from multiple systems to a single printer or bank of printe

r

s being offered as a common service. When a connection request is made while the printer is

I eing used by another

I

85

Terminal Servers on Ethernet Local Area Networks

system, the connection request can be queued. This queuing provides a basic mechanism for sharing printers among multiple systems.

Some of Digital 's personal computers now implement the master end of the IAT protocol and can operate as simple single-session terminal servers. These servers are implemented as part of

the DECnet-DOS and ProjDECnet releases and allow the PC to emulate a terminal connected to a terminal server. Combining this feature with the servers that offer services, a PC user can con­ nect to any PC that is connected to a terminal server for file transfer applications, to a dial-out modem, or to a non-LAT host system . Data integrity is provided "end-to-end" in PC-based implementations due to the lack of twisted pair, or simihir, wiring. Figure 7 shows the connec­ tions to asynchronous printers and IAT from per­ sonal computers.

Within the IAT environment, the service name offered by a host system does not always have to represent the command interpreter on a given system, though this is by far the most common use today. Instead, a service name could repre­ sent an application program, which might be run automatically when a connection request is made. Alternatively, using the solicited-connec­ tion mechanism currently employed for printers,

DECnet-DOS

VAX/VMS HOST

D ECserver 1 00

applications programs could initiate connections to terminals (or other asynchronous devices) located within the LAN.

DECserver 200

The DECserver 1 00 interconnects terminals in an office environment at a very low price. Soon after it was announced, it became clear that modem-controlled lines and connections to non­ rAT host systems should also be priced just

as low.

Thus the DECserver 200 project was initi­ ated to produce a new server based on the DEC­ server 1 00 design, but with modem control capa­ bilities. Moreover, this product had to meet the original cost goals of the DECserver 1 00. This project involved a redesign of the printed circuit board, yet retained the same system architecture. A faster version ( 1 0 MHz) of the same MC68000 microprocessor was used, and memory was increased from 1 28KB to 384KB of RAM and

from 5 1 2 bytes to 2KB of

NVRAM

. This increase

allowed room for the implementation of modem control software and support for non-IAT hosts (i.e. , reverse-rAT capabilities) . The increase also allowed a larger service directory database to be stored and an enhanced on-line help capability to be added. PRO/DECnet NON-LA T HOSTS ETHERNET TERMINAL SERVER ETHERNET TERMINAL SERVER .

TERMINALS ASYNCHRONOUS TERMINALS DIAL-IN ASYNCHRONOUS

PRINTERS MODEMS PRINTERS

Figure 7 Asynchronous Printers and LA T on PCs

86 Digital Tecbnicaljournal

No. 3 September 1986

1 New Products

1_.,

::_

Figure 8 DECserver 200

Another feature of the DECserver 200 takes advantage of the new DECconnect cabling scheme, allowing coQnections to be made using DEC423 wiring. This feature allows communica­ tions at up to 1 9.2 Kbau.d over cable that is nei­ ther twisted pair nor shielded, for relatively long distances of up to 1 000 feet. Figure 8 shows the DECserver 200 hardware.

Summary

Unlike other existing packet-oriented transport layer architectures, the LAT transport layer implements asymmetric connection manage­ ment, asymmetric data flows, and timer-based message exchanges.

The most unusual innovation of the IAT archi­ tecture is the use of multicasting as a presenta­ tion level naming service . On Ethernet, packets are normally addressed to the adapter of a . specific system. However, the Ethernet specifica­ tion describes a form of logical addressing called multicast addressing. In this scheme a packet addressed to a multicast address is received nearly simultaneously by many independent sys­ tems. LAT uses these messages to completely configure the topology automatically. This action means that installing a terminal server is as simple as plugging it into the Ethernet and wait-

ing for services to be advertised. ·

Asymmetric connection management consider­ ably simplifies the complexity of the protocol in which terminal servers initiate connections to host systems. If a host system wants to connect to a terminal server, that connection must be solic­ ited from the terminal server. This protocol solves the problem of having many host systems

Digital Technical journal

No. 3 September 1986

competing independently for the same resource. The first "solicitation" is serviced by a connec­ tion, and subsequent requests are queued on a first-in, first-out basis.

I

On a particular terminal s�rver, all devices that are logically connected to the same host system share messages both to and from that host . Within each message, each user's data is con­ tained within slots. This �ultiplexing, in con­ junction with the delay ti

m

er, reduces further the number of messages e:?cchanged. For exam­ ple, as more users log in to a host system, the number of messages exchanged remains con­ stant at approximately 1 2 per second in each direction, even as the lengths of the messages increase.

The DECserver 1 00 and · DECserver 200 are low-cost implementations of the IAT architec­ ture, allowing terminals and other asynchronous devices to be configured in a flexible and cost­ effective manner in a LAN ..

Acknowledgments

,

Over the years, a large number of people have contributed to the architecture and products described in this paper. The authors acknowl­ edge, with gratitude, all this work. In addition, a number of people have taken the time to review this paper and have made

!

many helpful sugges­ tions; to these. people we a.lso extend our thanks.

References

1 . J. Morency et al., ''The: DECnetjSNA Gateway . I

Product - A Case St;udy in Cross Vendor

Networking,'' Digit

l Technical journal

(September 1986, this issue) : 35-53. 87

Paul R. Beck james A. Krycka

The DECnet-VAX

Product

An Integrated Approach

In document dtj v01 03 sep1986 pdf (Page 85-89)