CA1206269A - Communication bus interface unit - Google Patents

Abstract

ABSTRACT OF THE DISCLOSURE

Apparatus and a related method for interfacing digital devices with a communication bus in a local-area computer network. Each device in the network is con-nected to the bus through a bus interface unit providing the device user with the ability to establish a connec-tion with another device by means of a simple CALL
command that does not require the use of physical iden-tifiers. The unit also allows the user to enter a TALK
mode in which a two-way conversation may be conducted over the network without the intervention of a host computer. A REMOTE command allows an unattended device to be controlled from another user site and also permits one user to connect two remotely located devices. A
message command allows a message to be stored and held for a remote user, again without the intervention of a host computer.

Description

COMMUNICATION ~US INTERFACE UNIT

BACKGROUND OF T~E_INVENTION

This invention relates generally to local-area computer networks, and more particularly, to an inter-face unit for connection between a communication bus andany of a variety of devices~ such as computer~, display and keyboard terminals, and printers. As computers have become less expensive and more numerous, there has been an increasing demand for simple techniques that permit interconnection of compwters, terminals and computer peripherals, such as printers. When connected to a network, relatively inexpensive desk-top computers can gain access to larger comlputers and to high-speed printers and large-capacity memory devices.
Another advantage of computer networks is that the uqers of the interconnected devices may communicate with each other by what is now referred to as electronic mail. In a typical electronic mail system a "host"
computer accepts and temporarily stores messages trans~
mitted ~rom one use~ to another. The messa~es may be immediately forwarded to their destinations, or may be held until the intended recipient connects wi~h ~he host computer and "picks up" his electronic mailD In any event f a host computer is required to aot as the "post office" in most mail systems of this type.

~,. ...

6i~

Of course, computers may be interconnected through telephone lines~ using a relatively simple modulator-demodulator (modem) for connecting each com-puter or terminal to the telephone circuit. Again, at least one device in such a network, usually the host comp~ter, has to supply the 7'intelligence" for directing the steps of communication among the connected devices.
This invention, however, is concerned with a different type oE network, referred to as a local-area network, in 10 which the connected devices are usually located in a relatively small geographical area. For example, many offices of a corporation may have a number of terminals, computerC and other devices connected to a single local~
area network. This would allow all of the network users to share the same data bases, to have access to the same computer programs, and to communicate with each other in day to day activities. More specifically, users could access the same word-processing programs and text files, could use a common telephone directory, and could gener ate and distribute internal me!moranda and reports over the network.
A variety of local-area networks have been developed in recent years, employing differing network topologies and differing commullication protocols. This invent~on is specifically concerned with networks having a simple bus topology9 to which each of the connectable devices D or "nodes,' is connected through a bus interface unit. Access to a communication bus may be regulated by a number of different approaches~ One is to allocate time to each connec~ed node on some uniform ti~e division multiplexing basis~ A more common approach is to allow any node to transmit on the bus when ready to do so, but to provide some means for sensing whether another trans-mission is also taking place. The latter is sometimes referred to as a carrier-sense multiple access system.

The present invention is embodied in a system employing this latter approach~ although the princip]es of the invention could be applied to systems employing other schemes for controlling bus access.
The use of a bus interface unit between a network device and the communication bus is not new in itself United States Pat. No. 4,161,786 to George T.
Hopkins et al. discloses a digital bus communication system in which bus interface units are connected between the bus and the "subscriber devices." The bus interface units in the Hopkins system appear to be used in part for participating in the control of access to the bus.
Broadly stated, the function of any bus inter-face unit in a local-area network is to provide modula-lS tion and demodulation of messages, and to some degree, toformat messages ~or transmission and to detect and decode receieved messages. Although a variety of local-area network equipment is available todayr the establishment of a communication link from a terminal to a computer on ~0 the network is not convenies~tly made. Moreover, a certain amount of computing power in the nature of system overhead, either at the host computer or at an intelli-~ent terminal, is required to establish and maintain the link~ Communication between relatively 'Idumb" ~erminals 25 i5 usually made through a host computer, and then not in a conveniently conversational mode.
Ideally, a bus interface unit for use in a local~area network should render the bus as "transparent"
as possible to the user~ In other words, each u~er should be able ~o communicate with any computer, device, or other user terminal on the network without concern for the nature of the bus, the message formats used, or the physical location or address of the intended destina-tion. Furthermore, a bus interface unit should ideally be small in ~ize and relatively inexpensive, unlike most D~

of ~he units that have been available for similar pur poses. The present invention meets or exceeds these ideal requirements.

SUMWARY OF_TEIE INVENTION

The present invention resides in a bus inter-face unit for use in connecting one or more digital devices to a local-area computer network. Of the various novel aspects of the invention, one of the most important i5 itB ability to cvoperate with another bus interface unit connected to the network and establish a virtual communication link between two devices, such that no other device can communicate with either of the linked devices until the virtual link is broken. Significantly, a device originatin~ a virtual link with another device need refer to the other device only by an ~ssigned name, which is totally independent of the device s physical address or identification.
Basically, and in ~eneral terms, the bus interface unit of the invention is for use in a local-area computer network having a communication bus and aplurality of user devices connected to transmit and receive information over the bus. The bus interface unit of the invention comprises means for connecting the unit to a plurality of user devices, each of which is capable of transmitting information to or receiving information ~rom the unit~ and means for connecting the bus interface unit to the communication bus through a plurality of logical portsO Most importantly, the unit also includes logical switching means for each user device, switchable between a command mode in which information from the user device is not passed to the bu~, and a connected mode in which inormation from the user device is passed to the bu~ through its corresponding logical port, and informa-tion xeceived from the bus through the same logical por-t is passed to the user device.
That logical switching means is also switchable from the connected mode, in which the user device is logically connected to a remote device through the bus, to a talk mode, in which information entered into the user device is automatically trans-mitted to the connected remote device when a special character is encountered in the inEormation, and that information when entered into the connected remote device is transmitted to the bus interface unit and is automatically output to the user device when a special character is encountered in the information.
More specifically, the bus interface unit also includes means for processing commands received from each of the user devices, means for use when the bus interface unit is functioning lS as a calling unit, for transmitting the name of a called bus inter-face unit to all other bus interface units in the network, and means for receiving an acknowledgement message from a called bus interface unit with a name matching the transmitted name, and for transmitting a connect request to the called bus interface unit.
The logical switching means then functions in response to the receipt of a connect request acknowledgement message from the called bus interface unit and switches to the connected mode, whereby the calling and called devices are then logically connected for the transmission of further data messages.
From the standpoint of a recipient of a call, the bus inter-face unit includes means for transmitting an acknowledgement if the received name matches the name of the unit, and means for transmitting a connect request acknowledgement if a port is avail-able for connection to the calling device. If connection can be made, the logical switching means in the recipient bus interface unit is then switched to the connected or data mode to establish the logical connection between the calling and called devices.
Once a logical link has been established as described above, another novel aspect of the interface unit is that the calling unit may establish a two-way conversational connection between the linked devices, whereby the logical switching means of the calling unit is placed in a mode known as the talk mode.
In the -talk mode, information entered into the calling device is transmitted automatically to the called device whenever a ;~ , selected character is encountered in the entered informa-tion, and informa~ion en~ered into the called device is likewise transmitted automatically to the callins device whenever the selected character is encountered in the entered information. More specifically, the interface unit when ~sed as an originating unit further includes first storage means for temporarily holding information entered into the callin~ device, and second storage means for temporarily holding information entered into the ca~led devicec Also included is means responsive to the detection of the selected character in the stored infor-mation, for transmitting the con~ents of the first storage means to the called device and transmitting the contents o~ the second storage means to the calling device.
In accordance with another aspect of the invention, the logical switching means of the bus inter-face unit is also switchable on comman~ to a remote mode, in which a local device is connected thro~gh the bus to another bus interface unit, which may then be remotely commanded to perform a number oE selected functions. In this manner a bus interface urit may be completely unattended and controlled from a diferent location.
Once in the remote mode, a bus interface unit may be commanded to leave a message for a remote user. For this purpose, each bus interface includes storage means for holding such messages~ any of which may be received from other interface units operating in the remote mode, and a visible indicator automatically actuated when the storage means contains a message. Each bus interface unit also include means for retrieving messages from the storage means. In one mode of operation the means for retrieving messages is operable only after entry of a specific password, so that privacy of personal messages may be maintained.

~2~,6~

In -terms of a novel method, the invention in its broadest sense is for use in a local-area network having a communication bus, a plurality of user devices and a plurality of bus inter-face units connected between the devices and the bus, and it compxises the steps of detecting a CALL command at an originating bus interface unit (~IU), requesting connection to a recipient BIU identified by name in the CALL command, an~ determining at the xecipient BIU whether connection may be completed.
If connection can be completed, the inventive method proceeds with the steps of establishing a first logical data path between the user device and a bus port at the originating BIU, establishing a second logical data path between a user device and a bus port at the recipient BIU, and establishing a third logical data path between the ports of the two ~IU's.
As mentioned above, a conversational "talk" mode is also an important aspect of the invention. When this mode is requested by an originating device, the logi.cal connection is established as described above; followed by the steps of switching the logical switching means in the originating unit to the talk mode, in which information en-tered into the calling device is echoed back to t:hat device character by character, but is also transmitted to the called device whenever a special character, such as a carriage return, is encountered.
Information entered into the called device is transmitted to the originating bus interface unit, where it is echoed bac~ to the called device and also sent to the calling device line by line whenever the special character is encountered. In this manner, everything entered into the calling device is viewed line by line on the called device~ and vice versaO
In operating a bus interface unit remotely, the method steps include switching the originating bus interface unit into remote mode~ and entering further commands at the originating end, to be executed by the remote unit, which functions in the same manner as if it were executing commands entered through one of its local devices. One of the commands entered remotely may be a message command. On receiving the message command the unit stores an accompanying message in a storage area and activates an indicator to advise the user that a message has been entered. The user may retrieve any stored messages by accessing the bus interface unit with a "view'l command~ If any message has been transmitted using a command that preserves privacy, the view command has to be preceded by an "open'~ command, with which the user must supply the correct password for access to ~he messages. ~essages transmitted on an open basis are termed announcements and may be accessed without a password.
It will be appreciated from the foregoing that the present invention represents a significant advance in the field of local-area computer networks~ In par ticular, the invention provides a novel technique for logically connecting two user devices, or a user device and a computer, in such a manner that the linkage may be established without knowledge of the physical address or physical identifying codes o the called device, and may be maintained without interruption un~il the linkage is broken. In addition~ the invention al70ws the establish-ment of a conversational talk mode between two user devices, without the intervention of a host computer to monitor or relay the message~. Finally, the bus inter-face units of the invention may be accessed and operated remotely, for unattended operation or for storage of messages intended for a user who is temporarily absent from the device location. These and other aspects and advantages of the invention will become apparent from the following more detailed description, taken in conjunction with the accompanying drawings.

BRIEF DI~C RIPTI~N 07 5~1E D~:IMGS

FIGURE 1 is block diagram of a local-area computer network of typical configuration, incorporating bus interface units in accordance with the invention;
FIG. 2 is a simplified, fragmentary block diagram showing the connection of two ~us interface units to a sending bus and a receivin~ bus of a local-area computer network;
FIG. 3 is simplified block diagram of a logical switching arrangement that is key to the opera~ion of the bus interface unit of the invention;
FIGo 4 is a diagram showing the format of a data packet used for transmission of data and control messages in the local-area network;
FIGS. 5a-5c are diagrams illustratiny the logical connectlons made in connection tables of ori-ginating and recipient bus interface units, for data mode, talk mode, and remote mode, respectively;
FIG. 6 is a simplified hardware component block diagram of the bus i.nterface ~nit of the invention;
FIG. 7 is a more detailed block diagram of a portion of the bus interface uni~ hardware of FIG. 6, showing in particular the relationship of the synchronous data link control (SDLC) logic to the other hardware components;

FIGS. 8a-8c together comprise a flowchart defining the sequence of functions performed by the bus interface unit in response to a CALL command, a PCA1L
command and a REMOTE command, Fig. 8c appearing with Fig. 8a;
FIGS. 9a and 9b together comprise a flowchart defining the sequence of functions performed by the bus interface unit in response to a TALK command;
FIG. lO is a flowchart defining the sequence of functions performed by the bus interface unit in response ~o an announcement (ANN~ command and a message (MESS) command;
FIG. ll is a flowchart of a task swapping program employed in the bus interface unit to share procesing time among a number of tasks to be excecuted together;
FIG. 12 is a state diagram illustrating opera-tion of the bus interface unit in transmitting a message using normal contention protocols;
FIG~ 13 is a state diagram illustrating opera-tion of the bus interface unit in transmitting an im-mediate acknowledgement message;
FIGo 14 is a state diagram illustrating opera-tion of the bus interface unit in receiving a connection request message and a disconnection request message;
~5 PIG~ 15 is a state diagram illustrating opera-tion of the bus interface unit in pro~essing the various stages of a CALL command sequence;
FIGo 16 is a state ~iagram illustrating opera-tion of the bus interface unit in handling the receipt of data messages; and FIG. 17 is a state diagram illustrating opera-tion of the bus interface unit in handling the transmis-sion of data messages.

DESCRIPTION OF THE PREFERRE~ EMBODIMENT

As shown in the drawings by way of illustra-tion, the present invention is principally concerned with improvements in the field of local-area colmputer net-works. In particular, the invention relates to improve-ments and simplifications, from a user standpoint, relating to the manner in which user devices are inter-connected in the network, and improvements in the types of communication modes that are available to a user without the support of a host computer connected to the network.

Local-area Network Description~

FI~S. l and 2 show the type of network environ-ment in which the invention operates to advantage.
As shown in ~IG. l, the typical network inc:Ludes a plurality of user terminalsl indicated by reference numeral 20, located at various sites that are usually in a relatively ~mall geographic area, such a5 in one building or a group of buildings occupied by a single company or organization~ The communication link connect ing the terminal is a bus 22, to which each terminal 20 is connected throu~h a plurality of bus interface units 24. In fact, each bus interface unit ~which will now be referred to only by its abbreviation BIU) is connec~ed to a sending bus 22a and a receiving bus 22b~ but as shown in FIGo 2, tne sending and receiving buses are joined at what is referred to as the head end of the bus~ which may include an amplifierO
The bus 22 may take a variety of forms, but in the presently preferred embodiment of ~he inven~ion, the bus is a broadband coaxial cakle and the messages are transmitted in the form of an amplitude~modulated 6~

radio-frequency carrier signal. This choice has the advantage of allowing the use of standard, relatively inexpensive cable-television technology for much of the bus equipment. In addition, since only a portion of the bandwidth of the cable is used or digital communica-tions, the cable may serve other purposes in some appli-cations. For example, closed-circuit television signals may be also transmitted over the network betwe~en remote locations.
Also connected to the bus ~2 in the typical configura4ion is a mainframe computer 26, which may employ more than one BIU 24 in connecting to the bus, to provide computer access for multiple concurrent users.
The computer 26 willy of course, be connected to the usual range of peripheral devices, such as a magnetic di~k drive 28, magnetic tape drive 30, and a high-speed printer 32. The computer 26 may also be connectable to communication lines, as indicated at 34, for exchange of information with remotely located computers. Some of the user sites may also have printers 36 available to them, although it is not usually economical to support every site with printing capability.
In many applications, the computer 26 acts as a "host" to the user terminals 20, any of which may connect to t~e computer in order to access a large data base or to control the execution of programs in the computer. In some systems, the computer 26 also acts as a host for the collection and distribution of ~electronic mail," a term that is intended to cover all forms of user-to-user 30 communicationsn In prior networks of this general type, communication with another device on the network is established by means of a calling sequence in which the destination device must be addressed by some form of hardware identiPier, which sometimes relates to the settings of switches on each BIU 24.

To reduce complexit:y and cost~ each BIU in networks prior to ~he present invention is associated with only one user device. As shown in FIG~ 2, each BIIJ 24 of the inventior, may have connected to it more than one user device, indicated by reference numeral 38.
FIG. 1 shows that one of the devices may be one of the printers 36, which may then be independently accessed from another device. In the embodiment described in this specification, two devices 3~ may be connected to each ~IU 24r but the BIU is designed for easy expansion of the number of user devices per BIU.
In accordance with one important aspect of the invention, ea~h BIU 24 in the network may be addressed by a simple name, the assignment of which may be readily changed by a user. As will be discussed in detail, a communication link may be established by the simple expedient of typing such a command as CALL SMITH~BILL at a user terminal. Data may then be transmitted to Bill Smith s terminal. Connection with a computer can like-wise be established by keying in a command such as CALLCOMPUTER,A. Even more powerful is a conversational mode established by keying in a command such as TALK
SMITHrBILL. In thi~ mode of opleration, everything keyed in at one of the linked terminals appears on the screen of the other, and a conversation may take place without the entry of further commands. Importantly, the talk mode functions without the help of ~ host computer. It is purely a user-to-user communication mode.
Another novel feature o~ the invention is a command that allow~ a user to control remote and un-attended device from his own terminal~ When the command REMOTE is entered, together with the name of another user device, the ~IU at that device becomes controllable by the user who gave the REMOTE command. With this feature at his disposal, a user canr for example, connect a remote unattended terminal ~ith a printer at a third site~
Yet another novel feature is the ability to leave a message at anotheL- user site, either a private message or a non-private "announcement," and again without using a host computer for this form of electronic mail. Access to a private message left for a user requires a special user password.
These and other aspects of the invention will now be discussed in more detail. However, some pre-liminary discussion of the hardware configuration of each of the BIU s 24 is first necessary.

The Hardware Confi~uration-As shown in FIG. 6, the major components of the LIU 24 are centra.l processor unit (CPU) logic 40, input/output ~I/O) logic 42, direct memory access (DMA) logic 44, synchronous data link control (SDLC) logic 46, a random-access memory (RAM) 48, a read-only memory (ROM) SO, and an electrically erasable programmable read-only memory (EEPROM) 520 These logic modules communicate with each other over a sys~em data bus 54, a system address bus 56 and a system control bus 58.
The CPU logic 40 is of conventional design and includes a Z80A CPU (a "ZILOG"* 4~SHz 8-bit micro-processor) and a standard ZILO~ counter/timer circuit(CTC)o The I/O logic 42 includes a standard ~ILOG Z80A
dual asynchronous receiver/transmitter (DART) chip, which is coupled to two serial I/O ports indicated at 60 and 62~ The DMA logic 44 includes a ZILOG Z80A DMA control chip~ which handles all data transfers between memcry and the SDLC logic 46, without .in~olving the CPU logic 40.
The 5DLC logic handles data transfers to and from the communication bus 22, and also includes other control *trademark logic discussed in more detail with reference to FIG. 7.
The memory devices are also conventional, including the RAM 40, which in the illustrative embodiment includes 6~144 bytes (6k) of memory comprising three RAM circ~its with part no~ M58725. The ROM 42 includes 12k bytes of memory, comprising three circuits with part no. 2732A.
F`inally, the EEPROM 52 comprises 2k bytes (part no~
2815?, and i5 used for storing information that may be changed but is not to be lost when power is turned off.
For example, BIU names and locations are stored in the EEPROM 52, using EEPROM write control logic 640 The ROM
50, of courser contains the programs and control logic necessary to perform the BIU functions to be described, while the RAM 50 is used for temporary data storage, Not shown in FIG. 6 is a modem (modulator/
demodulator)~ which is connected to the SDLC logic 46 over lines 66~ The modem transmits message packets over the communication bus ~2 by amplitude-modulating a radio frequency carrier signal, and receives message packets by demodulating the received carrier. In addition, the SDLC logic 46 also exercises some control over the DMA logic 44~ as indicated by line 72.
FIG. 7 shows the SDI',C logic in more detail, including a standard SDLC chip 74 (part no. WD1933B-02 manufactured by Western Digital), a first-in~first-out chip 76 (Zilog 128-byte FIO chip, part no. Z3038)1 and a bi-directional bus driver 78 ~part no. 74LS245) connect-ed between the system data bus 54 and a local data bus 79. Basi~ally, the FI~O circuit 76~ which is also interposed between the local data bus 79 and the system data bus 54r acts as a buffer mechanism between the SDLC
and DMA chips, so that these two circui~s can run asynch-ronously. The 5DLC logic 46 also includes an array of discrete logic elements, indicated by reference numeral 80, which ln turn includes DMA con~rol logic 82, data ~ ~r-g 3J~

transfer cont:rol logic 84, bus arbitrat.ion logic 86, end-of-packet detection logic 88, and I/O decoding logic 90. The bus arbitration logic 86 controls use of the local. data bus 79, as well as the direction of data transfer in the bus driver 78, as shown by control line 92. Data flow between the SDLC chip 74 and the FIFO
chip 76 is controlled by the bus arbitration logic 86 and the data transfer control logic 84, and data flow between ~he FIF~ chip and the RAM 48, via the DMA logic 44 and the system data bus 54, is controlled in part by the data transfer logic. The CPt) logic 40 can send control information to the SDLC chip 74 through the bus driver 73 and the local data bus 79, and status information from the SDLC chip can be sent to the CP~ logic over the reverse path, again under control of the bus arbitration logic 8~
In addition to its functions described above, the local bus 79 is also used to transmit CPU control information to a system control I/O port 93O This is used to generate miscellaneous I/O control signals to the E~PROM 64 and to audib.Le and visible indicators on the bus interface unit.
The bus arbitration logic 86 and the end-of-packet detection logic 88 also communicate with the CPU logi~ 40 over a CPU wait line 94 and a CP~ non-maskable .interrupt l.ine 96, the latter being used to notify the CPU logic of completion of eitner an outgoing data transfer through the SDLC chip 74, or an incoming data transfer from the SDLC chip to memoryO The I/O
decoding logic receives address and control informa~ion from the system address bus 56 and system control bus 58, and provides I/O control signals on lines 98J also used in the control of various input and output operations.
The entire discrete logic array 80 is implemented in the form of three logic array chips, two having part no.

PAL1018 and the other having part no. PAL16R6~
The detailed logic design of the hardware elements shown in FIGSo 6 and 7 is not in any way criti-cal to the invention as claimed, and other desiqn ap-proaches might be e~ployed to couple the BIU to thecommunication bus 22 and to local device ports. For the sake of completeness, however, complete schematic diagrams of the hardware are included in Appendix I to this specification.

Overview of Modes of Operation~

The BIU of the invention provides each user with a convenient in~eractive technique for communicating with other users or computers connected to the networkO
The basic or default mode of the BIU is the command mode. It should be remembered throughout the descrip-tions that follow that the "mode" or "statel' refers not necessarily to a BI~ but to a logical portion of the BI~
that is handling a particular device connected to the BIUo The BIU may, for example, be in the command mode ~0 with respect to device #1 and in a data mode with respect to device #2.
In the command mode, the BIU receives and interprets information entered into the user device, checking to determine whether any of the information contains one of its list of valid commands. In this mode~ the user is communicating with his local BIU and not with the communication bus 22. When a command is recognized by the ~IU, it takes appropriate action to comply with the command. Some of the commands are merely request6 for status information that can be immediately supplied to the user terminal. For example, a status command, STAT, provides the user wi~h the current status of the BI~ to which his device is connected. Other commands are used to modify various parameters relating to the BI~. For example a NAME command is used to assign or modify a user s name, and a LOCATION command is used to enter or modify a user s location~ After any of the S foregoing commands f the requested action is taken by the BIU and control is returned to the user in command mode~
The commands with which the present invention is principally concerned, however; are those of the type that place the BIU in a different mode of operation.
There are three other modes of operation that are of interest~ da~a mode, talk mode, and remote mode. In data mode, the local user device is logically connected to another device, usually a computer, but in some instances another user device. In data mode, the logi~al connec-tion is initiated by an originating device, and informa-tion subsequently entered into or originating rom the originating device is treated as data to be transmitted to the device with which the logical connection has been established. A CALL command is used to establish the initial connection and effecl: transition to the data mode.
In accordance with ar. important aspect of the invention, the only parameter needed for the CALL command is the assigned name of the intended destination BIU.
Each BIU in the network actually has four names, includ-ing a first and last name, a location name and a BIV
name, which is the serial number of the deviceO The CALL
command may use any two of these four names, and typic-ally uses the first and last names. For user terminals,the first and last names can be conveniently selected to be the first and last names of the users themselves. For computers, the names can be well Xnown computer names identifying the computers, such as "VAX", "IBM"
Itrademarks) and so for~h.

In the talk mode, a logical connection is established as in the CALL command t and then additional changes are made to the BIU logic, to establish an interactive link with the called device, which is usually another user terminal. In the talk mode, any information entered by the calling user is automatically displayed at called user s terminal, and any information entered by the called user is auomatically displayed at the calling user s terminal~ In this manner, a two-way conversation can be carried on, all without the intervention of a host computer.
In the remote mode, which is entered by giving the REMOTE commandl a user can access a remote BIU as if it were his own. when used in conjunction with the CALL
command, REMOT~ allows one user to interconnect two devices at second and third sites, which may be unat-tended. When used in conjunction with the remote mode, a message command (ME5S) allows a user to store a message at a remote BIU, for later viewing by a user at the remote site. Access to the message can be gained only by using an OPEN command, which requires entry of a user passwordl followed by a VIEW command r and terminated by a CLOSE command.
The manner in which these functions are per-formed will be discussed in the following descriptivesections. Fuctioning of the BIU can be discussed at a number o~ different levels of operation. Basicallyl it is tlle CPU logic 40 that controls the various func~ions under the control of a set of programs of instructions stored in the ROM 500 A listing of these programs is provided in Appendix IIa However, it will be appreciated that the programs are necessarily complex in structure, since the CPU must perform a number of functions, such as input and ou~put, in a practically simultaneous manner.
~or this reason the programs are structured as a number of separate tasks that share the the CPU under the control of a task swapping program that switches Erom one task ~o another in rapid succession~ Further compli-cating the program structure are a number of program segments that are executed in response to interrupt signals provided to the GPU logic, to indicate, for example, that a data packet has been transferred onto the bus or has ~een transferred into memory from the bus.
The program task structure will be described later, since it does not serve as a convenient vehicle for explanation of the invention.
Operation of the programs embodying the inven-tion will instead be explained at a functional and sequential level rather than ocusing on the specific program code~ Each principal command will be explained with reference to a flowchart of the sequence of func-tions involved, and with reference to a logical table structure manipulated by the programs, Operation o the BI~ will also be discussed using logical state diagrams, which provide a usefl.~l aid in visualizing the effect on each BIU during vari.ous steps in the command sequences.
A logical table structure is manipulated by the programs to establi.sh desired connections between devices, logical bus ports, ancl processing tasks, and to maintain and subsequently dismantle these connections.
An understanding of this table structure, at least in logical term~, is essential to an appreciation of the functions of the CALL, TALK and REMOTE commands~ and combinations of these and other commands. The table structure is shown in simplified form in FIG. 3~ as incl.uding a character~oriented table, indicated as CODTAB, a packet-oriented table, indicated as PODTAB, and selectably switched logic, indicated at lOO. The struc-35 ture of the tables will not be described in detail, and ~2~

is available in the listing of Apppendix II. Suffice it to say~ however, that the two tables and the switched logic 100 together establish various data paths through the BIU.
Entries ~9 and #10 in the CODTAB, referred to as COD~9 and COD-10, respectively, are logically linked to two local I/O ports, indicated at 102 and 104, respec-tively, for two local devices. When in the command mode, the only linkages provided by the switching logic 100 are the command mode links indicated by broken lines 106 and 108. Link 106 connects COD-9 with COD-l and link 108 connects COD-10 with COD-2. Logically connected with COD-l is a command interpreter module 110, which has a keyboard buffer associated with it. Each of the lin~s 106 and 103, and in fact each oE the other links to be described in relation to the switched logic, may be cons.idered as a bi-directional data path. Thus, when the user at device $1 sends characters of informati.on through port local I/O 102, each character is transmitted over link 106 tc the command interpreter 110. One of the functions of the interpreter :is to initiate an "echo"
transmission of each received character bac~ to its source, in this case over the l:ink 106 to the originating device. A~ a result~ the user will see the characters he enters displayed on the screen of his terminal. The interpreter 110 also functions to store the received characters in the keyboa-rd bufEert and to interpret the received information and take appropriate action if the information constitutes a command.
Basicallyr the information or data are not moved at all in effecting data transfers in the tables, over lines such as the link 106. Rathert pointers in the tables are modified to reflect apparent movement of the data.
Associated with COD-~ is another command interpreter 112, performing an identical function to the other interpreter 110, but for information received over link 108 from port 104 to device #2. In fact, the two command interpreters 110 and 112 are implemented in the form of a single program. However~ the program is designed to be "re~entrant," meaning that it may be called or entered from more than one calling program, without waiting for completion of any previous calls.
This presents the appearance of the availability of multiple copies of the same program. Associated with COD-5 and COD-6 are two auxiliary huffers 114 and 116, respectively, under the comrnand interpreters 1~0 and 112, as indicated by the broken correcting lines. These auxiliary buffers are used only in the TALK command, lS to be discussed. I'here is also yet another command interpreter 118 and associated buffer logically connected to COD-O. This is used only in relation to the REMOTE
commandO
Thus far in discussing the CODTAB and PODTAB
tables, only the command mode has been considered, and no connections with the PODTAB have been discussed. The PODTAB also contains a plurality of entries, of which only #0, #1 and #2 are shown. Entries #1 and #2 are connected to logical bus ports #l and #2, respectively.
Port #l is the port through which device ~1 accesses the busl and port #2 is the port through which device #2 accesses the bus. In accordance with the connections to be described for various commands, the switched logic 100 may be modified to include linkages from a CODTAB entry to a PODTAB entry~ to connect a device to its output po~t.

The CALL Command:

The CALL command establishes a logical connec-tion be~ween a calling device and a called device. The logical connection is stored in the CODT~B and PODTAB
entries in the BIU s at both ends of the connection.
However, before the table entries are modified to record the connection, there is an exchange of messages between the calling and called BIU s, first to locate the called device, then to attempt a connection with ito Beore the nature of these messages can be discussed~ it is appro-priate to digress to define the format of a message packet used in transmitting data and control messages over the communication bus~
The message packet format is shown in FIG. 4.
It includes a field for a destination addre~s, defining a unique BXU, and a destination port within a BIU. Some messages will be broadcast to all destinations, in which case the destination address will be all zeros. The packet also includes fields for a source address and source port within the source BI~ Then there is a command field indicating the type of information con-tained within the packet, a packet length field, and avariable-length field for data to be transmitted.
Finally there is a field for a cyclic redundancy code for error checking purposes, and a two-byte field for an end-of-packet flag.
The various types of information that may be contained in a packet are given by the following table, each entry in which has a unique command code for entry in the message packet command code f ield:

Mnemon ic Message Type ACK Acknowledge data WAC Wait acknowl edge NAC No~data acknowledge CRA Connect-request acknowledge C~B Connect-acknowledge busy ~2~2~

QAA Query acknowledge acknowled~e NRA Name request acknowledge DIS Disconnect QBN Query-by-name RSM Resume with data DAT User data packet CRQ Connect request NRQ Name request QNA Query name acknowledge The purpose of each type of message will beco~e apparent as the description of each command proceeds, especially in relatlon to the state diagrams.
The CAL,L command will now be described with reference to the flowchart of FIGS~ 8a-~c. The CALL
sequence is entered as shown at 120. The normal CALL
command assumes that the caller does not wish to be connected to a specific port of the called BIU. Typic-ally, the user will use CALL to connect with a computer or to reach a ~ser who has his own BIU. In the computer situation, the ~ser has no preference for which port is employed to access the computer. A variant of the CALL
command is the PCALL, a~ shown llt 123, which requires the caller to specify which port he wishes to connect to.
This might be used, ~or example, when a u~er wishes to connect his terminal to a printer located at a remote site and connected to the bus through a speific BIU portO
In any event, for a plain CALL, parameters are set to select any port, as shown at block 122~ and ~or a PC~LL
the parameters are set to select a specific port, as indica~ed at 124~ It happens that the REMOTE command, indicated at 125, is also a variant of the CALL, and that the parameters are then set for the selection of port #0, as indicated at 126. The effect of the REMOTE command is discussed in more detail below.

-25~

Each form of the CALL, command next requires that a connection be performed, as indicated by the block 128, which is expanded in FIG. 8b, describing a sub-routine named SYMCOM. After return from SYMCOM if a successful connection was made, indicated by an affirma-tive answer to the question posed in block 130~ a suc-cessful return is made from the call sequence~ as indi-cated at 132. If the connection was unsuccessful, a message indicating that the remote BIU is busy is dis-played to the caller, as indicated at 134~ and an errorret~rn is made, as indicated at 136.
The connection process is shown in more detail in FI~. ~b, which first asks, in block 138, whether a PODTAB entry is connected to a port to the bus, and then enters at 140 a subroutine called GETNMS to obtain the names of any BIU s matching the names given as parameters in the CALL command. GETNMS i~ shown in detail in E'IG.
8c. The sequence is to first allocate a table area for receipt of responses, in block 142, then enter a query-by-name phase (block 144), bu.ild a query-by-name message packet (block 146), transmit the packet (block 148)5 place any responses in the allocated table (block 150), and return the calling BIU to an idle status ~block 152) beore returning to the calling programO
~5 Back in the SYMCOM subroutine~ a check is made to determine whether any responses were re~eived to the query-by-name message (block 154~. If none were re-ceived~ an error return route is taken, but if there were any valid responses the first is retrie~ed for further processing (block 156). ~p to this point, the calling BIU has transmitted a broadcast query-by~name tQ~N) message to all other BIU s on the network, and has received one or more replies from BIU s that have names matching those specified in the CALL command~ Where several BIU s are connQcted to a single computer, they will be assigned the same nam~e, which gives rise to one situation in which there could be multiple replies to a Q~N message. The calling BIU saves the source addresses of all of the QMA (query name acknowledge) responses and sends off an immediate QAA (query acknowledge acknow-ledgej in each case.
In decision block 158 of FIG. 8b, it is determined whether connection to a specific port is required. If so, indicating a PCALL or REMOTE command, an attempt is made to connect with the required port Iblock 160), and if successful (block 162) a successful return is made from the ~YNCOM subroutine. The attempt to connect to the port, in block 162, basically involves the transmission of a connect request (CRQ) message to the remote BIU, which then has to check a field in the appropriate PODTAB entry to determine whether connection to another BIV has already been made. The remote BIU
transmits either a connect request acknowledge (CRA) message if the port is available, or a connect acknow-ledge busy (CAB) message if the port is unavailable. Ifthe required port is busy, as determined in block 162, or if there is no free port available for a CALL command, as determined in block 164, the next entry in the table of successful name matches is retrieved (block 166), and control is transferred to block 158 again to try to establish the connection. If there are no more entries in the table (block 168~ a return is made indicating ~hat all ports are busy, as indicated at 170.
In processing the CALL command at block 164, if a port is available an attempt is made to connect to it (block 172), ~nd if successful, as determined i!l block 174, a s~ccessful return is made, as indicated a~ 176.
Otherwise, a search is made for another port o~ the same BIU (block 178)~ and control is transferred back to block 172 to attempt another connection. If all of the ports ~;D6,~

have been tried (block 180), control is transferred to block 166 to look for another BIU table entry.
An important part of the CALL command sequence takes place when a successf~l connection has been made to a remote BIU. At this point the CODTAB and PODTAB
entries at both originating and recipient BIU s are changed to establish the logical connection between the called and calling devices5 This is shown for the CALL
in FIG. 5a. In the originating BIU~ a connection is made between COD-9 and POD-l, indicating that device #l is logically connected to its bus port (#1). Contained within the POD-l entry is the BIU address and port number of ~he recipient of the CALL. This is essentially a POD
tc POD entry in the table t as indicated by the broken line between POD-l of the originator BIU and POD-2 of the recipient BIU. It is assumed, by way of illustration only~ that connection was made to the second port at the recipient BIU, either because there was a PCALL command specifying that port, or because it was ~he only avail-able port.
Note that the command mode link between COD-9 and COD-l no longer exists in FIG. 5a after the CALL.
Data entered into device ~1 of the originator BIU will be transferred over the established call linkage to device #2 of the recipient BI~. The protocols for data transfer are disc~ssed below in relation to E`IGS. 16 and 17.

The TALK Command and Mode:

Now that the CALL command and the sequence of operations it .initiates have been described, ~he power of the TALK command can be better appreciated. As shown in ~he flowchart of FIGS. 9a and 9b, the TAL~ command sequence begins by initiating an ordinary CALL command, as indicated at 190. Next there are two calls to a -28~

subroutine named ATTACH, at 192 and 194. The first ATTACH call at 192 has the effect of removing the CALL
linkage established in the originator BI~, and establish-ing an alternate linkage. In the example of FIG~ 5, the CALL linkage between COD-9 and POD-l is first removed and a new linkage is made between COO-9 and COD-l. It will be recalled that this is the command-mode link shown in FIG. 3, and that COD~l has a command interpreter and keyboard buffer associated with it. The second ATTACH
call, at 194r nas the effect of making a connection between POD-l and COD~5, which, it ~ill be recalled, also has the command interpreter 110 associated with it, together with the auxiliary bu$fer 114. Both buffers are initialized in block 196, then the characters entering the buffers are examined one by one and echoed back to their respective source devices. For example, a charac-ter from the local device is placed in the keyboard buffer and echoed back to the local device, over the COD-l to COD g link. Likewise, a character from the remote device reaches the auxiliary buffer over the POD-l to COD-5 link and i5 echoed back to the remote device over the same link. The connect:ions at the recipien~ BIU
are the sa~e for TALK as they are for CALL.
Action of the commancl interpreter 110 operat-ing in rrALK mode is diagrammed by the remainder of the flowchart of FIG~ 8a. Character by character examination is eFfected by calls to a subroutine named DOCOD, at blocks 198 and 200. If a carriage return character is detected in the keyboard buffer (block 202), a call i5 mader in block 204, to another subroutine (P~TBUF), whose function is to transmit the entire buffer to the other device, i.eO to the remote device. This function is performed by manipulating the table entries and pointers again~ In effect, a line of information in the keyboard buffer is transferred by the command interpreter 110 to ~Zl~
--2g~

the COD-5 entry point to the tables; and then passes over the llnk already established from COD-5 to POD-l, to reach the remote device.
Similarlyl when a carriage return character is detected in the au~iliary buffer (block 206), a call is made to PRTBUF (block 208) to dump an entire line of the buffer to the local device. In this case, information in the auxiliary buffer 114 is transferred to COD-l, and thence over the link established to COD-9 and the local device. By now it will be understood that, once the TALK linkages have been established, the local user at the originator BIU may "talk" to the remote user device by simply keying in a message. Ater every carriage return, a line of the message will be transmitted to the remote device. In a similar fashion, each line that the remote user enters will appear at the local device.
FIG. 9b shows detail of the DOCOD subroutine used to pr~ces~ characters in the buffers in the talk mode. In the first decision block at 210, a check is ~ade to de~ermine whether a rel:urn is to be made to the command mode. If so~ the command mode linkages are restored (block ~12), and an appropriate ret~rn is made as indicated at 214. If not, the appropriate COD entry i5 checked for an indication of the presence of another character (block 216~, and return is made to the calling program if there is no character to be processed If a character is to be processed, it is determined in block 218 whether it is a control characterO If so, and if it is a carriage return ~block 220), a carriage return and a line feed are echoed back to the source of the character (block 222) and a carriage return flag is set for use by the calling program. If the control character is not a carriage return~ it is processed (block 224) before return to the calling program. If the character i5 a printable character ~block 226), it is echoed back to its source device (block 228) before a return to ~he calling program.

The REMOTE Command and Mode:

As discussed above, the REMOTE command is processed as a variant of the CALL command sequence, the only difference being that the REMOTE command specifies cQnnection to port #0 at the recipient BIU. The signifi-cance oE this connection will be apparent from FIG.
5c. The originator connections are the same as for a CALL, namely from COD-9 to POD-l in the example. At the recipient BI~, connection is made from POD-0 to COD-0, and it w:ill be recalled that there is another command interpreter and buffer associated with the COD-0 entry of the table~ After entering a successful REMOTE command, the originatiny user's terminal will appear to be still in command modeO Everything entered into the terminal will be echoed back, not by the originating BIU, but instead by the recipient BIU. The originating user is effectively in control of the remote BIU instead of his own~ and may issue any of the usual commands, which will be executed by the remote BIU.
Probably one of the most powerful aspects of the REMOTE command is ~hat it permits a user to effect a connection of two other devices, located at two remote and unattended sites. Suppose, for example~ that there is a high-speed printer connected to port #2 of a BIU
named BILL SMIT~, and that there is a terminal connected to port ~l of a BIU named JAKE JONES. A user at yet another BIU could connect the terminal to the printer by means of the command sequence REMOTE JONES,JAKE (to gain remote control) PCALL SMI~H,BILL,1,2 (to connect Erom the terminal on port #l ~f the Jones BIU to the printer on port #2 of the ~mith BI~.) ~3 The Messa~e and Announcement Commands-. .

These commands may be issued in the remote mode, in which case their effect i5 to store a message at the remote ~IU. They may also be issued in the command mode. For example, a user may leave an announcement on his own bus interface unit to explain his absence to other users. The only difference between the two com-mands is that the announcement (AMN) is not private and may be viewed by anyone accessing the BIU to which the message is directed. A message command (MESS), on the other hand, may be viewed only by someone with knowledge of a unique BI~ password. An appropriate flag is set to indicate which type of command (ANN or MRSS) has been made, as indicated in blocks 230 and 232 in FIG. 10.
From this point on~ the functions performed in executing the two commands are the same. The privileged flag set or not set in blocks 230 and ;232 will not be consulted until a VIEW command is attempted, to view the stored message. If the message is private, an OPEN command will be required, to provide the password.
The message sequence ollows the steps of locking access to system message buffers temporarily, while this message is being stored (block 234), and looking for 2 free message block (blocX 236)o If no 25 message block can be found (block 238), the system message buffers are released again (block 240) and a return is made to the calling program~ If ~ free message block is found, in block 23B, the block is ta~ged as busy ~block 242), block pointers are initiali2ed ~block 244), and the contents of the keyboard buffer are transferred to the message block, in block 246. Then the block that was being used is set as available (block 248), a beep tone is turned on to indicate the stored message ~block 250~, a light is turned on for the same purpose ~hlock 252~, and the system ~uffers are released (block 254) before return to the calling program~

Task or~anization:

The foregoing functions have been described in terms of sequences of operations performed by the BIU.
In fact the various functions are performed or at least initiated by a number of separate program modules called tasks. Switching from task to task is controlled by a program called SWAP, a flowchart of which is shown in 1~ FIGo 11~ Each task makes calls to SWAP on a very fre-quent basis, and on each entry to the SWAP program the calling task is suspended and another task is reacti-vated. SWAP activates tasks on a simple round-robin basis in a continuous sequence. Operation of the SWAP
program wlll first be described, and then the various tasks identified.
On entry to the SWAP program, the calling task s registers are first saved, as indicated in block 260, and then a watchdog timer is reset, in block 262. A
watchdog timer is a device commonly emplo~ed in real-time computer systems to ensure that certain key func~ions are performed on a timely basis. The watchdog timer causes an interrupt signal if it is not reset within a predeter mined time, and the interrupt signal can be used to 25 reinitialize the entire system if necessary. Since the SWAP program is supposed to be entered on a frequent basis; ailure to call SWAP can only mean some type of malfurlction that calls for recovery measures to be taken.
Another important ~unction performed by the SWAP program is to service the CODTA~ and PODTAB en-tries. At decision block 264, i~ is determined whether it is time to service the CODTAB entries. This decision ~2~

is based on an examination of a memory location to see whether it is zero or not. An interrupt service routine is used to set the memory location to a non-zero value at a rate of 160 Hz. When the non-zero value is detected in block 264, a branch is made to a routine called TIMEDX, 5 shown in block 266, which is responsible for servicing the CODTAB entries. In the present embodiment of the invention, there are a total of sixteen entries in CODTAB, although not all of them are used~ On each entry into TIMEDX, one entry of the CODTAB is checked to see whether any action is required, and the memory location checked in block 264 is reset to zero. Thu~ the entire CODTAB is serviced at a rate of 10 Hz.
It is estimated that the SWAP program is entered at a rate of several thousand times per second.
On all of its other entries when a branch is not taken to the TIMEDX routine, the alternative branch is taken to a routine called UNLOAD, in block 263. Servicing the CODTAB entries in the TIMEDX rcutine involves checking each entry to see whether a packet of information is to be transferred over one of the C'OD to COD links or one of the COD to POD links established in the data rnode, the talk mode, or the remote modeu Xf a transfer is to be made and can be made, a program operating under TIMEDX
effects the transfer by appropriate manipulatlon of the table pointers. It will be recalled that there is~
strictly speaking, no movement of information over the table links, only a logical movement of information effected by changing pointers that define the location of the information in relation to the I/O ports and processing tasks associated with the tableO
In servicing the PODTA~ entries, the UNLOAD
routine performs a similar function for PODTAB that the TIMEDX routine performs for CODTABo Each PODTA~ entry is checked in turn to determine if any transfers are to be ,

2~

~34-made t and the transfers are made whenever possible.
The remainder of the SWAP program is relatively routine. In block 270 a pointer to the current task s saved registers is also saved, then in block 272 the identity of the next task to be entered is obtained. As already m~ntioned, this is done on a simple round-robin basis. If the task can be presently run (block 274~, a new pointer to a stack of saved task registers is ob-tained (block 276), the new task s registers are restored (block 278) r and control is transferred to the new task by executing a return, as indicated at 280.
Task #0 is initially a system initialization task whose function is to initialize the entire system, including certain variables in RAM and EEPROM. It also initiates operation of the other tasks. After this initialization phase, which is executed only when power is first applied to the BIU, or when the BI~ is reset to an initial state for some reasonl task ~0 becomes a program called CCPTSK. This is a continuously executing task that handles various operations requested by the system, such as updating the actuation of visible and audible indicators, and handling of QBN (query by name) calls.
Task #l is designated OUTSDL and is the central program handling outbound SDLC information. Basically it is responsible for sending packets to the bus when they arrive at the PODTAB entries. Task #l is also respons-ible for inputting packets to a data receiving BIU
operatiny in what is referred to as receiver-driven mode. The receiver-driven mode will be discussed witn reference to the data-mode ~tate diagrams (FXGSo 16 and 17), but in brief it simply means that data transfers are being made under the control of the receiver rather than the transmitter of the data.
Tasks ~4, ~5 and #6 are all identical command interpre~er tasks designated as CIL~ Task #4 is associ-ated with entry COD-0 in the CODTABy and is used at a recipient BIU in a REMOTE command, to interpret commarlds from the originator BIU. Tasks #5 and ~6 are associated with entries COD-1 and COD-2, respectivelyl and are used to interpret commands from local devices, as discussed in relation to the various commands.
Overlaying the task structure, are a number of executive request routines made from the tasks, and a number of interrupt response routines to which control is transferred upon the receipt of interrupt signals from the input/output devices. A complete description of these programs would add little to an understanding of the present invention~ which relates specifically to various modes of connection and communication between u~er devices. If further detail is required as to the operation of specific routines or tasks, the complete listing of all CPU programs provided in Appendix II may be consulted.

~ID

The state diagrams of FIGSo 12 17 do not always relate directly to the programs and executable tasks that have been de~cribed, but the diagrams do provide a useful pictorial ~epresentation of the se~uences of events related to various BIU functions. Each circle in the diagrams represents a state of the BIU~ or more pre-oisely~ a state of part of the BIU, since the BIU can assume different states for different ones~of its con nected devices. The paths drawn between the state circles each represent a change in state, in the direc-tion of the arrowhead on the path, caused by a "~rigger"
event written above a horizontal line appearing in a break in the path. In most cases, the "trig~er" event J~

causes an "action,~' written beneath the horizontal line in the transition path, as well as the change in state.
FIG. 12 shows the action of a transmitting BIU
in sending a message in accordance with normal contention protocols. This means that the message packet is transmitted after a delay of 200 microseconds, pro~ided that the bus is still not busy at the end of the delay.
State 0 is the initial idle state of the BI~. When a request is received that requires the transmission of a normal contention protocol reply, the BIU goes either to state l, if the bus is not busy, or to state 2 if the bus is busy. In state 2, the transmitting task is suspended temporarily~ but will be frequently resumeci to return to state 0 again, until such time as the bus is no longer busy~ In state 1, a delay of 200 microseconds is allowed to elapse. Then, if the bus is still not busy~ the message is transmitted and the unit goes to state 0.
However, if the bus is busy at the time the delay is completed, the task will be suspended by a call to the SWAP program and the BI~ will go to state 2. When the SWAP program resumes execution of the transmitting task, a return will be made to state 0, and if the bus is then no longer busy, there will be a transfer to state 1 again to wait out a new delay period before transmittingD
FIG~ 13 shows the corresponding state diagram for an immediate acknowledgement transmission. Whatever state the BIU i5 in when it receives a message that requires an immediate responser the appropriate acknow-ledgement message is constructed and transmitted imme-diately. As will be seen, this has the advantage of providing a response to a request of some kind, such as a connect request, without having to wait for the req~lisite time delay in normal contention responses. In making an immediate response, the BIU does not relinquish the bus until the response is sent. The carrier signal is maintained and no other BIU can gain access to the bus until the immediate response is completed.
FIC~ 14 is a state diagram showing BIU in various states when subject to connection and disconnec-tion requests. In state 0 the BIU is in a ready anddisconnected state. If a correct request CRQ message is received when not busy, in state 0, an immediate connect request acknowledge (CRA~ is transmitted and the BIU goes into state 1, which is the busy and connected state. If a connect re~est (CRQ) is received when in the busy state, an immediate connect acknowledge busy (CAB) message is transmitted. When a disconnect (DIS) message is re-ceived, the BIU reverts to state 0 again. The same thing happens i~ the BIU is requested to initiate disconnection itself, by transmitting six consecutive DIS messages.
FIG. 15 is a state diagram relating to the CALL
command sequence. When in state 0, the initial state, the BIU receives a CALL command and transmits query by name (QBN) message, moving to state 1, where it waits for responses. If no resp~nses are received within a predetermined time, the BIU returns to state 0, b~t if a q~ery name acknowledge (QNA) i5 received, the BIU trans-mits an immediate query acknowledge acknowledge (QAA) and goes to state 2, where additional QAA responses may be recelved and handled the same way. When the time allowed for responses is up, the BIU selects the first response that it received and goes to state 3, where an attempt is made to achieve connection with the called BIU.
A connect request (CRQ) will be transmitted up to eight times when in this state 3. If an immediate conneot request acknowledge (CRA) is received on any try, the BIV returns to state 0 and reports a successful connection. If an immediate connect acknowledge busy (CAB) message is received, the port is set to a busy status and the BIV goes to state 5~ where another port is selected. State 5 is also reached if no response is received after eight tries to connect. IE another port is available, return is made to state 3 to try up to eight more connect requests. If no other port is avail-able on the first selected BIU, transition is made tostate 4, where another BI~ is selected from the responses received to the original QBN message, and trarlsition is made to state 3 to try to connect with the next BIU. If no further BIV s are available and no connection has been achieved, transition is finally made back to state 0 with an error indication.
State diagrams for the PCALL and REMOTE com-mands are similar in most respects to FIG. 15. The only difference is that state 5 does not exist for those commands, since a specific port is selected for connec-tion.
FIG. 16 is a state diagram showing the various states of a BIU acting as a receiver in a data transmis-sionO It should be reviewed in conjunction with FIG. 17, 20 which shows the corresponding states of a BIU acting as a transmitter in a data transmission. IN FIGD 16, state 0 shows the receiver in a ready state. If a data packet (~AT) i~ received while in this state~ the immediate response is an acknowledge (ACK~, and this sequence would normally continue until all the data had been received.
This i5 referred to as the sender driven mode of data transmissionO
If the receiver is busy, as shown by state 1, a received data packet (DAT) will generate an immediate wait acknowledge (WAC) transmission and the recelver will go to state 2~ indicating that a transmission is pend-ing. If a further DAT message is received while in this state, a further immediate WAC message will be sent in replyO When the receiver becomes not busy, it will transmit a resume with data (RSM) message, go to state 3, and wait for a data transmission. If there is no further data, a no data acknowledge (NAC) message will be re-ceived and the BIU will return to state 0. If a DAT
message is received, the receiver responds with an ACR
and returns to state 2. Further data will not then be accepted until another RSM message is transmitted. This is referred to as the receiver driven mode of data transmission~ The BIU will not remain in state 3 in-definitely, of course~ It will transmit up to ten RSM
messages, and if no further data or no data acknowledge (NAC) is received, will transmit a disconnect (DIS) message six times and go to a disconnected state, shown as state 4. In the disconnected state, further data messages will be ignored, and no further data transmission can occur until connection is re-established and a returr~ made to state 0.
From the transmitter standpoint, FIG. 17 shows an initial state 0, in which the BIU first receives a re~uest to send data. It transmits a DAT packet and waits in state l for an acknowledgement. If the ACK
message is received, the transmitter returns to state 0, ready to send more data. This is the sender driven mode. If no ACK is received afl-er a time-out period) the DAT message is retransmitted, and this sequence may be repeated up to ten times before going to a disconnected state, state 5. If, while in state l, a WAC response is received, the transmitter goes to state 2, where it waits for a RSM message from the receiver. It has now entered the receiver driven mode~ When a RSM message is re~
ceived, the transmitter immediately sends aro~her DAT
packet, and goes to state 3 to wait for an ~CK response.
If no response is received after a time-out period and ten retries of the data transmission, the BIU goes to state 5 ar.d is disconnected. If an ACR is received as a resul~ of the last data transmission, the transmitter goes temporarily to state 4O From there, if there is more data to send, the BIU returns to state 2 and waits for ancther RSM message before transmitting. If there is no further data to send, the BIU will stay in state 4 until another RSM message is received, then will transmit a no data ackno~ledge ~NAC) messa~e and return to state 0. Upon reaching state 5 by either of the paths shown in FIG. 17l the BIU has to be reconnected before going to state 0 again to reinitiate data transmission.
It will be appreciated from the foregoing that the present invention represents a significant advance over bus interface units used in local-area networks of the prior art~ In particular, the invention provides a novel technique for establishing a logical connection between two user devices on the network, and fo~ estab-lishing a conversational TALK mode without the interven-tion of a host computer. In addition the invention provides for a REMOTE mode in which a user may control a remote bus interface unit, and may store messages at the remote unit. It will also be appreciated that, although a spe~ific embodiment of the invention has been described in detail for purposes of illustration, various m~dif.ications may be made wit;hout departing from the spirit and scope of the invention. Accordingly, the invention is not to be limited except as by the appended claimsO

Claims (19)

The embodiments of the invention in which an exclu-sive property or privilege is claimed are defined as follows:

1. For use in a local-area computer network having a communication bus and a plurality of user devices connected to transmit and receive information over the bus, a bus interface unit comprising:
means for connecting said bus interface unit to a plurality of user devices, each of which is capable of transmitting information to or receiving information from said bus interface unit;
means for connecting said bus interface unit to the communication bus through a plurality of logical ports; and logical switching means for each user device, switchable between a command mode in which information from the user device is not passed to the bus, and a connected mode in which information from the user device is passed to the bus through its corresponding logical port, and information received from the bus through the same logical port is passed to the user device.

2. A bus interface unit as set forth in claim 1, wherein:
said logical switching means is also switchable from the connected mode, in which the user device is logically connected to a remote device through the bus, to a talk mode, in which information entered into the user device is automatically transmitted to the connected remote device when a special character is encountered in the information, and information entered into the con-nected remote device is transmitted to said bus interface unit and is automatically output to the user device when a special character is encountered in the information.

3. A bus interface unit as set forth in claim 2, and further including:
information processing means coupled to said logical switching means and connected in the command mode to receive information from the user device, said infor-mation processing means including means for echoing each character of information back to its source and means for identifying commands in the information.

4. A bus interface unit as set forth in claim 3, wherein:
said means for identifying commands functions in response to identifying a "talk" command by switching said logical switching means to a talk mode in which said information processing means receives information both from the user device and from a remote user device with which connection is made;
said means for echoing each character of information back to its source is operative for both sources of information; and said information processing means further includes means for detecting a special character in the information from either source, and in response trans-mitting to the other source all of the information accumulated prior to the special character.

5. A bus interface unit as set forth in claim 3, wherein:
said means for identifying commands functions in response to identifying a "remote" command by switch-ing said logical switching means to the connected mode, and effecting switching of a remote bus interface unit to a remote mode in which received information is inter-preted for commands to the remote bus interface unit.

6. For use in a local-area computer network having a communication bus and a plurality of user devices connected to transmit and receive information over the bus, apparatus comprising:
at least two bus interface units for connection between the bus and user devices, said bus interface units being arbitrarily designated originating and recipient units, each of said bus interface units in-cluding information processing means, for storing and analyzing characters of information from a user device, including means for echoing characters back to the source and means for identifying commands in the information, and logical switching means having a first set of terminals connected one to each user device associated with said bus interface unit, a second set of terminals connected one to each logical port to the bus, at least one terminal connected to said information processing means, and having means for interconnecting said terminals to form logical message paths;
means initially active in the originating unit, for switching said logical switching means to a command mode in which a local user device is connected to said information processing means;
call request means activated in the originating unit upon identification of a CALL command in said information processing means, for requesting connection of the local user device with a device at the recipient unit, which is identified only by name in the CALL
command;
call request processing means activated in the recipient unit for determining whether connection may be made in accordance with the CALL command;

first link storage means activated in both units after a successful connection request, for switch-ing said logical switching means to a DATA mode in which a local device on one of the first set of terminals is connected to a port to the bus; and second link storage means activated in both units after a successful connection request, for storing the location and port of the other bus interface unit, with which connection has been established.

7. Apparatus as set forth in claim 6, where-in:
said call request means, call request process-ing means, first link storage means and second link storage means all function in the same way to establish a logical connection in response to a TALK command made at the originating unit;
said apparatus further includes talk switching means operative to modify said logical switching means in the originating unit, such that said information process-ing means receives information both from the local device and the remote device; and said information processing means further includes means responsive to detection of a special character, for transmitting information received from one source to the other source, whereby the local and remote devices are connected in a conversational talk mode.

8. Apparatus as set forth in claim 6, where-in:
said call request means, call request process-ing means, first link storage means and second link storage means all function in the same way to establish a logical connection in response to a REMOTE command made at the originating unit;

the connection made in the recipient unit is between a specially reserved bus port and said informa-tion processing means; and information entered into the local user device of the originating unit is processed for commands in the recipient unit, whereby the originating unit appears to be command mode, but is actually relaying commands to the recipient unit.

9. Apparatus as set forth in claim 8, where-in:
said information processing means in the recipient unit further includes means for processing a message command, storing a message for a recipient user, and activating a message indicator.

10. For use in a local-area computer network having a communication bus and a plurality of user devices connected to transmit and receive information over the bus, a bus interface unit comprising:
means for connecting said bus interface unit to a plurality of user devices, each of which is capable of transmitting information to or receiving information from said bus interface unit;
means for connecting said bus interface unit to the communication bus through an equal plurality of logical ports;
logical switching means having for each user device a command mode in which information from the user device is not passed to the bus, and also having for each user device a connected mode in which information from the user device is passed to the bus through its corres-ponding logical port, and information received from the bus through the same logical port is passed to the user device;

means for processing commands received from each of the user devices;
means for use when said bus interface unit is functioning as a calling unit, for transmitting the name of a called bus interface unit to all bus interface units in the network;
means for receiving an acknowledgement message from a called bus interface unit with a name matching the transmitted name, and for transmitting a connect request to the called bus interface unit; and means for receiving a connect request acknow-ledgement message from the called bus interface and switching said logical switching means to the connected mode in response to receipt of the acknowledgement, whereby the calling and called devices are logically connected for the transmission of further data messages.

11. A bus interface unit as set forth in claim 10, wherein:
said logical switching means is also switchable to a talk mode in which said means for processing com-mands is connected to receive information both from a local user device and a connected remote user device;
and said means for processing commands includes means for echoing each character of information back to the source from which it was received, and means respon-sive to a specific character in the received information, for transmitting information received from one source over to the other source, whereby information entered at each connected device appears also at the other device.

12. A bus interface unit as set forth in claim 10, wherein:
said means for processing commands operates in response to a REMOTE command to initiate connection to a special port of a remote bus interface unit, the special port being connected to means for processing commands at the remote unit, whereby the remote unit will accept commands from a local device.

13. For use in a local-area network having a communication bus, a plurality of user devices and a plurality of bus interface units connected between the devices and the bus, a method comprising the steps of:
detecting a CALL command at an originating bus interface unit (BIU);
requesting connection to a recipient BIU
identified by name in the CALL command;
determining at the recipient BIU whether connection may be completed; and if connection can be completed, establishing a first logical data path between the user device and a bus port at the originating BIU, establishing a second logical data path between a user device and a bus port at the recipi-ent BIU, and establishing a third logical data path between the ports of the two BIU's.

14. A method as set forth in claim 13, where-in:
said method includes a first step of detecting a TALK command;
said requesting, determining and storing steps are also performed in response to detection of a TALK
command; and said method further includes the subsequent steps of modifying the first logical connection to connect the user device and the bus port to an information storage and processing module, identifying a special character in infor-mation received either from the originating user device or the recipient user device, and transmitting, in response to the special character, information received from one source over to the other source.

15. A method as set forth in claim 13, where-in:
said method includes a first step of detecting a REMOTE command;
said steps of requesting, determining and storing first and third logical corrections are also performed in response to the REMOTE command; and said step of storing a second logical connec-tion effects connection between a reserved bus port and a command processing module at the recipient BIU, whereby commands entered at the originator BIU device are exe-cuted at the recipient BIU.

16. A method as set forth in claim 15, and further including the steps of:
entering a MESSAGE command at the originating BIU device; and executing the MESSAGE command at the recipient BIU, including the steps of storing a message accompany-ing the command, and activating a message indicator.

17. A method as set forth in claim 16, and further including the step of:
retrieving the stored message at the recipient BIU.

18. A method as set forth in claim 15, and further including the steps of:
entering a CALL command at the originating BIU
device; and executing the CALL command at the recipient BIU, including the step of logically connecting a device at the recipient BIU to a device at a third BIU.

19. A method as set forth in claim 13, and further includint the steps of:
transmitting a data packet from the originating BIU to the recipient BIU;
receiving an acknowledge data message from the recipient BIU and repeating said transmitting step in response thereto;
receiving a wait-acknowledge message from the recipient BIU;
switching to a receiver-driven data transmis-sion mode in response to the waiit-acknowledge message;
receiving a resume-with-data message from the recipient unit; and retransmitting the last data packet in response to the resume-with-data message;
whereby data transmission takes place in a sender driven mode until a wait-acknowledge message is received, after which the transmission takes place in receiver-driven mode.