NO174910B - Computer input / output network - Google Patents

Description

This invention relates to the improvement of the input/output part of a computer, and is particularly useful for a cost-effective connection to the computer of a relatively large number of input/output devices or peripheral devices of low to medium speed spread over a relatively large geographical area to achieve efficient time sharing of the computer system's resources and efficient communication between the input/output devices and the computer system.

Background for the invention.

The increasing demand for time sharing of computer resources among a number of different external I/O devices of relatively low speed has led to many changes in computer architecture over the years. A good number of these changes have concerned the in/out subsystem. I/O controllers are designed to avoid limiting the available speed of today's processor units and strive to serve an increasing number of I/O units. I/O controllers are usually either mass storage or character type. An I/O controller for mass storage is used to control the high-speed transfer of relatively large amounts of data from one or more external mass storage such as e.g. disk storage, via the computer's bus to the system's primary storage. Since the number of transfers to and from the mass storage is relatively small and the amount of data for each continuous high-speed transfer is relatively large, the efficiency of the mass storage channel controller's operation is usually not considered a significant limitation. One has, however, experienced significant limitations by attempting to transfer smaller amounts of data, usually characters, relatively often one after the other, which is the case with relatively many low- to medium-speed input/output devices such as e.g. terminals and printers. The character I/O device that has been developed in response to the increasing use of low to medium speed I/O devices has become more and more complex, and will soon provide diminishing efficiency relative to the improvements that may be achieved.

The most common version of I/O channel controllers uses its own, relatively complex processor to multiplex data to and from a certain number (8, 16 or 32) of connected I/O devices. The character channel controller's I/O ports may be limited to a specific type of device for dedicated local connectivity. If the character-channel controller is not device-dedicated, a correspondingly complex I/O adapter is required between the I/O channel and each device, possibly each group of devices. The operational functions of the I/O controller, the I/O adapter, the host computer, and the I/O devices are shared between all of these components. The communication and the protocol to achieve such communication is usually complex, requires significant redundancies in the operating system, usually complicates the transfer of I/O data and usually limits the processing capability.

Most costs in connection with connecting devices to the computer come as a result of the relatively complex mode of operation of the I/O processors in the channel controller and the adapters and protocol required. In order to reduce some of these relatively high costs, it is common to create many ports on each input/output adapter in order to connect many input/output devices. The I/O devices must usually be located physically close to the I/O adapter as the cable length can limit the speed at which reliable data transfer can occur. To connect a new I/O device to a computer in the event that there is no unused port on a multiport I/O adapter, a new multiport I/O adapter must be connected to the channel controller. The user's connection costs are not necessarily related to each new connection of an input/output device to the system, as the connection of each new multiport adapter entails having to pay for the opportunity to connect a number of input/output devices, whether these are used or not. In some situations, the connection costs may exceed the costs of the input/output device itself.

The method of multiplexing used in character input/output channel controllers and

-adapters can also create restrictions. One type of multiplexing is known as central query. In case of central query, the central processor sends requests to each input/output device in turn and independently of whether it has any data to send or not. Another form of polling, known as induced polling or on-demand polling, initiates this type of central polling only when an adapter sends a state-changed signal. With induced polling, one avoids the workload that continuously polling all the adapters and I/O devices is for the processor, but requires that all the adapters are polled once in sequence with a single query sequence. Querying requires significant programmatic functionality either at the processor unit or channel

the controller, and wastes time by both the active and the passive I/O devices being queried, and by interpreting the result of the query.

Another type of multiplexing is generally referred to as on-demand access. Access on request usually involves an access request from an adapter to the communication link, and a form of selection to distinguish between access requests from the different adapters. The signal delay in the selection system can create significant adverse effects. Since signal delay increases with increasing cable length, selection techniques that use the processor unit or system bus controller to sort access requests, known as central selection systems, are usually limited to the computer bus and other applications where the distance between the I/O adapters that generate the requests and the selection logic is maximum one meter.

Relay signaling is a technique for distributed control or selection that has been successfully used in local area networks.

US-4495493 describes a conventional network, and concerns media access control for the nodes of the local network. It is not relevant with regard to communication at session level: ""The upper levels, for example session, presentation, applica-tion (terminology OSI) cooperate with the lower levels but they will not be described herein because they are essentially formed by logic and are known". (column 7, lines 64-69). Accordingly, US-4495493 does not show or suggest a separate IONET communication protocol operating at a level above the local network communication protocol to establish session-level communication between session partners -devices without interference from other IONET messages throughout the session. Also not shown is inclusion of IONET messages in the data fields of local network data packets, transmission of control function information and byte stream data in single IONET messages to simultaneously perform control functions, while byte stream data is transferred unmodified to the devices , or the use of utility point bodies at each node to implement separate IONET com communication protocol.

In US-44574284, separate communication modes are required, such as one for data and another for control functions. Furthermore, a separate medium or cable set is needed to communicate control functions.

In US-4574284 it is shown that the bus interface units are switchable between a separate command mode where the information from the user device is not transmitted to the bus and a connected mode where the information from the user device is sent to the bus. With the bus, it appears that two separate and non-simultaneous modes of communication are accomplished; one to transfer byte stream data, and another to transfer control function commands. However, it does not include the advantage of simultaneous communication of management functional administrative information together with byte stream data, without terminating the session. Furthermore, US-4574284 uses reserved or special codes (e.g. carriage return) in byte stream data communicated to achieve certain control functions, and thus does not achieve transparent byte stream data transfer.

US-4423414 is relevant at a local network level in terms of a "local command".

Brief summary of the invention.

The present invention is designed as an input/output network (IONET) channel for a computer system. In general, IONET is intended for highly efficient character and

other communication between several low- to medium-speed units of the same or different types, connected directly to the I/O subsystem of a computer, by means of selection over a communication medium of the local area network type, relatively inexpensive adapters with microcomputers distributed over the medium and connected to each I/O device or a smaller number of I/O devices, and a communication and control protocol to effectively control the microcomputers and to manage the data communication between the I/O devices and the computer system's memory. The local area network type communication medium, the protocol and the distributed low-cost adapter together form an improved input/output channel controller, but without the limitations previously stated.

The I/O devices can be connected at significantly longer distances from the central unit, because the selection mechanism allows such connections without reducing the data transfer capability, and because local area networks provide reliable communication over longer distances than other solutions that use low-cost cabling. The communication and control protocol is relatively simple, does not require significant additional work, and provides efficient data transfer. The distributed adapters are relatively easy to implement and respond directly and efficiently to the protocol's commands for data transfers. The user incurs relatively low costs, fixed per connection, with each new connection of I/O devices to the system, thus avoiding the high cost associated with expensive single adapters for sharing logic as well as the restrictions on physical location when connecting the I/O device to these adapters. The input/output devices can be located in widely different places. The data transfer does not require time sharing by the much faster central unit, despite the fact that the communication takes place with input/output devices of significantly lower speed. Users of each I/O device have access to all of the system's resources without placing a complete computer system at each I/O device or terminal.

The present invention's protocol provides a significant conservation of the network's bandwidth, because it incorporates flow control at the transport level. Data packets will not be sent until it is clear that the packets can be received. The protocol is generally immune to the loss or duplication of any packet at any time. If a packet is duplicated or lost, the system will naturally recover at the transport level. Data messages can be forwarded between separate network segments. The invention can also allow a privately connected logical unit even in a multiprocessor system, which is very useful for security reasons, and limits access to the information. A significant part of the multiplexer function and network control function has been moved into the protocol.

The present invention can be better understood on the basis of the following detailed description of a preferred implementation of the invention, which is also illustrated in the accompanying drawings which are summarized below. The actual purpose of the invention is defined in the attached claims, and the description of the invention above should only be regarded as a general summary of special features.

Brief description of the drawings.

Figure 1 is a general block diagram of a typical legacy computer system in which a mass storage I/O channel, a character I/O channel and a local area network are connected. Figure 2 is a general block diagram of a computer system using the IONET channel of the present invention. Figure 3 is a block diagram illustrating the interconnection of multiple I/O channels using multiple IONET channels into a single computer system. Figure 4 is a block diagram illustrating the interconnection of multiple computer systems to multiple I/O devices using an IONET channel. Figure 5 is a block diagram illustrating the interconnection of multiple computer systems interconnected to a local area network, each computer system having an IONET channel connecting multiple I/O devices to each computer system. Figure 6 is a block diagram of a distributed adapter for the IONET channel connecting an I/O device to the IONET channel cable. Figure 8 is a block diagram of an example distributed adapter utilizing the RS 232 serial interface. Figure 9 is an illustration of the seven-layer Open System Interface (OSI) architecture which is the International Standards Organization's reference model for communication. Figure 10 is an illustration of an IONET packet of information sent over the IONET channel, shown in the form of sequential bytes (bit groups). Figure 11 is an illustration of the IONET packet as shown in Figure 10, broken down into the hierarchical levels corresponding to physical, link, network, transport and session levels in the OSI model. Figure 12 is a diagram illustrating in greater detail the bitwise layout and other details of some of the individual bytes of the IONET packets shown in Figure 10. Figure 13 is an illustration of a general state change diagram for a transmitter state machine for the distributed adapter for present invention. Figure 14 is an illustration of a general state change diagram for a receiver state machine for the distributed adapter of the present invention. Figure 15 is a diagram showing the operation of the transmitter state machine in normal mode. Figure 16 is a diagram showing the operation of the transmitter state machine in instantaneous mode. Figure 17 is a diagram showing the operation of the receiver state machine in normal mode. Figure 18 is a diagram showing the operation of the receiver state machine in instantaneous mode.

Detailed description.

The present invention can be better understood with reference to a computer system 100 of older technology, which is illustrated in Figure 1. The computer system 100 comprises the typical processor 102, which is connected to and can communicate with the typical primary memory 104. A typical I/O subsystem 106 is available for communication to and from primary memory 104. The processor 102, primary memory 104, and I/O subsystem 106 are all capable of communicating with each other with the high internal capacity or bandwidth that characterizes a modern computer system. The input/output subsystem 106 will have one or more connection options for external peripheral devices. These external connections are typically called in/out channels. In most modern computers, two types of input/output channels are available. One type of I/O channel is the mass storage I/O channel 108. The mass storage I/O channel 108 is characterized by providing the high bandwidth transfers that are typical of the storage media disk storage 110 and tape drive 112. A mass storage I/O channel 108 cinnamon 108 is typically limited to a couple of meters in length. A mass storage channel 108 is capable of making data transfers to and from only one I/O device at a time, although some mass storage channels are capable of handling overlapping operations where different devices access data simultaneously but only one physically transfers data always. In general, a mass storage channel is not optimized to handle low-speed or less coherent data transfers between the system's memory and I/O peripherals due to, among other things, relatively high cabling costs, relatively complicated interface circuits, restrictions in physical distances, as well as the optimization of the mass storage channel 108 for the transfer of relatively large blocks of data at each transfer.

To allow for a relatively large number of individual transfers of a relatively small amount of data, most computer systems have a built-in character input/output channel 114. The term "character" describes the most common usage, to transfer data units representing alphanumeric and special characters to and from external peripherals. However, the term "grade" does not imply the restriction that only grades can be transferred. Graphical data, arbitrary binary data and other information encodings can be transmitted over the character input/output channel 114. The character input/output channel 114 is characterized in that parallel or serial data bit transmission takes place at speeds that are generally lower than that of the mass storage channel 108 , but at a rate greater than any of the individual peripherals connected to the character in/out channel 114. The character in/out channel 114 is optimized for short transfers to a relatively large number of peripherals rather than long transfers to a relatively small number of units.

In small to medium computer systems, the most common way to connect peripherals is to use one or more multiport interfaces, or adapter 116 coupled to channel 114. Typically, adapter 116 will be part of the entire computer system 100. A number of low-speed, parallel or serial communication interface 118 emanates from computer system 100 and is electrically connected to, and communicates with peripheral devices such as terminal 120, printer 122 and modem 124. The interface 118 is typically low-speed communication cables which can be of limited length if no modem is used, is limited in speed normally to a maximum of a few tens of kilobits per second. second, and limits the system's capacity, because each of the cables 118 takes up considerable space on the back panel of the computer. Often, the number of external cables 118 that a computer system can provide is more limited by back panel space than the actual available bandwidth of the computer system.

Typically, it is also common to connect the multiport adapter directly to the input/output character channel 114, in or in the immediate vicinity of the computer case. However, such direct connection is limited to a relatively short distance, therefore the multiport adapter 116 must be placed at a distance that is not significantly far from the computer itself.

In most larger computers, the multiport adapter 116 includes a separate processor, often referred to as a front-end processor, which controls the communication and multiplexing between the various peripheral devices and the computer system 100. The functionality of the adapter 116 tends to be quite complex, and therefore requires a relatively complex and expensive processor by itself to prevent the processing needs to control the low speed I/O devices from overtaxing the control processor 102. Furthermore, the communication and protocol between the I/O subsystem 106 and the multiport adapter 116 tends to be complex and require significant internal communication management to and from the system memory 104, to provide multiplexing between the peripherals.

The cost of shared logic and the relatively complex hardware required in each of the multiport adapters 116 has required that they have the ability to connect to many peripherals, typically at least 4, usually 8 or 16, and sometimes 32 peripherals. Cost efficiency has thus been achieved, provided that there is indeed a large number of peripherals to be connected to each adapter 116. If all interfaces or cables 118 are occupied, it is necessary for the user to connect yet another multi-port adapter 116 to the computer system to make room to the next peripheral. The incremental cost of adding an additional peripheral can be extremely high or prohibitive, and may well exceed the cost of the peripheral itself. Furthermore, due to the distance limitations of the character in/out channel 114 and the length limitations of the interface cable 118, all peripherals must be physically located relatively close to the multiport adapter 116.

Devices that have largely the same characteristics as the multiport adapter 116 described above are sometimes referred to as input/output channel controllers.

In many cases, a local area network ("LAN"), designated 126, is also connected to the computer system 100. Typically, a "LAN" adapter 125 is used between the "LAN" media 128 and the input/output subsystem 106. This "LAN" adapter is most commonly connected to the character input/output channel 114. A "LAN" typically includes a network communication medium or cable 128 to which many computers are connected for the purpose of sharing information. Each of the computers is connected to the "LAN" cable 128 at a tap point 130. Each system connected to the "LAN" cable 128 at a tap point 130 is called a node. Different varieties of local area networks exist, such as character rings, character buses, conflict shared buses, etc. The most significant difference between the various conventional local area networks is based on how sophisticated the software is, and therefore can offer different degrees of resource sharing and functionality.

The network cable 128 can be stretched relatively long distances from the host or main computer 100 to the other nodes. Some of these nodes are other general computer systems 100. Some nodes in the local area network may be special devices known as front-end processors 132. Front-end processors are sometimes called cluster controllers. The front processors 132 do not provide general data processing capabilities, but act as a transparent interface element that allows connection of terminals 134 or other non-computer input/output connections. Although the cluster controllers are connected to the I/O subsystem 106 over the network 126 through a "LAN" adapter 125, the disadvantages discussed in the context of the multiport adapter 116, arising from the complex processing, cumbersome administration, and shared logic for multiplexing, also apply to each of the cluster controllers mentioned. It is quite certain that the cost effectiveness of each cluster controller 132 depends on connecting a relatively large number of input/output devices 134 over relatively short distances. The incremental cost of connecting more terminals to the local area network is usually magnified, as not all terminals can be located physically close to the cluster controller. As a consequence, more cluster controllers or other front-end processors must be connected than absolutely necessary just to accommodate the physical location of the I/O devices. This ratio contributes significantly to the cost of connecting several input/output devices.

In contrast to a prior art computer system, the present invention is presented generally in Figure 2. An input/output network (IONET) channel 140 is available to connect the computer system 100 to many input/output devices, e.g. terminals 142, printers 144, personal computers 146, various data acquisition equipment 148, modem 150, and static multiplexers 152. The modem 150 communicates over telephone line 154 with e.g. a remote computer system 156. The static multiplexer 152 communicates over the telephone line 158 to a corresponding remote unit 160. Many remote terminals 162 are connected to the remote static multiplexer 160. The static multiplexers 152 and 160 reduce telephone cost by combining the aggregated I/O the transactions going to and from the many co-located, remote terminals 162 on a common telephone line 158. What is referred to herein as an "in/out device" is a peripheral device that is not capable of operating on its own and requires some form of interface to connect to a computer, and is to be distinguished from "device" which has its own processor as described in greater detail below. An input/output device transfers input/output information.

The IONET channel 140 combines special characteristics of a local area network of the character transmission principle, and character I/O channel to achieve significant improvements in connecting a relatively large number of low to medium speed I/O devices to the computer system while avoiding many of the the significant limitations that exist in today's systems. Although the IONET channel 140 is primarily a character channel, various data streams can be routed over this channel and its use is not limited to character transmissions only.

The IONET channel 140 comprises a communication cable 170, multiple distributed adapters 172 coupled to the cable 170, and means for connecting to the computer system 100 is at node 174. The term "node" refers to the electrical connection to the cable, and is not to be confused with the term "node" which generally refers to any electrical equipment connected to a node, which is described in more detail below. The IONET channel 140 may become the means of interfacing connecting the computer system 100 to the various input/output devices. An I/O device is intended to include any variety of different types of non-processor, non-storage peripherals that can be connected to the IONET channel, such as terminals 142, printers 144, personal computers 146, data acquisition equipment 148, modems 150, static multiplexer 152 and its like.

The computer system 100 is simplified, as it does not need a separate local area network, multiport adapter, and various other capabilities in its own character input/output channel interface reportor. Furthermore, the computer system does not require the functionality of a network node in the "LAN" protocol to communicate with peripheral devices, and because of this, the computer system does not need to support a local area network protocol, if this is not required to communicate with other computer systems. In contrast to this, the protocol to be used in connection with IONET channel 140 is primarily intended as an interface to input/output devices, and not for resource sharing and interfaces to remote operating system functions. This means that the IONET protocol is relatively easy to implement at each remote input/output device using the distributed adapters 172.

The distributed adapters 172 do not need to be physically located in particular proximity to the computer system 100, but can be moved a considerable distance away. For example, in the preferred form of the present invention, the I/O devices may be located as much as over 6 km from the computer system 100. Data going to and from the I/O devices is multiplexed on a single serial cable 170. The distributed the adapter 172 is located in or near the input/output devices to which they are connected. An example of a distributed adapter that is placed within the I/O enclosures is in the personal computer 146, where the distributed adapter 172 is illustrated as enclosed in the same case as the personal computer 146.

To provide a much larger computer system having a large number of I/O devices connected, many IONET channels 140a and 140b can be connected to the same computer system as shown in Figure 3. Figure 3 illustrates how this method can be extended to support a large number of I/O devices without correspondingly increasing the number of cables going in and out of the computer system 100. By providing the low to medium speed communications at the computer system in the form of IONET channels as shown, and by distributing the functions that normally exist with multi-port adapters or front-end processors to many distributed adapters, the amount of space required on the panel, and internal cabling in the host computer will be significantly reduced. Furthermore, it is not necessary to have access to the computer's case to connect to peripherals. The communication bandwidth has not been reduced, as the aggregated bandwidth is measured by the many millions of bits per second with media of the local network type, rather than many thousands of bits per per second that is typical of low-speed communication cables coming out of a typical computer system.

Another significant configuration advantage of the present invention is illustrated in Figure 4. Conventional I/O channels, either mass storage type or character oriented, can be connected to only one computer system to form a channel to transfer data between the computer system and many peripherals. Due to the nature of the present invention, it is possible to connect many computer systems 100a and 100b to many I/O devices using a single shared IONET channel 140 as illustrated in Figure 4. Any of the I/O devices 176 can communicate with either computer system 100a or 100b. There is no limit to the number of such computer systems that can be connected to the IONET channel, other than that which may be provided by the aggregate bandwidth of the channel, and physical limit to the number of nodes the IONET channel 140 can support. This advantage is particularly important, because there is no physical switching or physical multiporting involved. This is in contrast to the conventional use of a multi-channel switch on a peripheral device or an I/O channel to switch between conventional I/O channels, and in contrast to switchboard or electrical switching systems available to control the connection of peripherals or multiple channels. Such conventional devices require increased cost and may decrease reliability, due to the additional hardware required to connect the particular peripheral to multiple I/O channels. Communication over the IONET channel is controlled by sending address signals, or characters, over the cable, which will be described in greater detail later. The interconnection capabilities are thus based on software and firmware operating in the computer system and in the distributed adapters, allowing each of the I/O devices to be connected in or out of the IONET channel by redirecting the characters. As no physical switching is required, a failure of one of the computer systems will not bind the device connected to that system, as the connection is logical. The present invention also incorporates security routines to allow an I/O device to appear to be connected directly to a single computer, despite the fact that there are many such systems on the same cable. These facilities are discussed in greater detail below.

The normal configuration of networked computers, all of which have the IONET channel, is shown in Figure 5. Two separate computer systems, 100a and 100b, are connected together to share resources by the single cable 128 of the local area network 126. Each of the computer systems 100a and 100b has an IONET channel, called resp. 140a and 140b, to which one can connect several input/output devices 176. The possibility that any input/output device 176 connected to each individual IONET channel has to access resources of computer systems other than the individual IONET channel is connected to, is a function of the local area network support in the operating system of each individual computer system, and will be available to the extent that the system programs provide. support for that functionality.

Another advantage that can be taken advantage of in the present invention, which is not particularly illustrated, but which can be understood on the basis of Figure 4, is the possibility of using the signal cable 170 to achieve the functionality of both the local network and the IONET character channel. In such a case, software within each of the computer systems 100a and 100b will support both that protocol between computers of the local area network, and the IONET protocol. Thus, a single cabling system is able to handle the combined traffic of resource sharing activities of the local area network, and the peripheral I/O activity of the IONET channel. Such an arrangement will utilize more bandwidth for transmissions within the same number of connected input/output devices, and should be used when the cable's aggregate bandwidth is sufficient to handle the combined load. When a single cable is split, this will provide a very economical way of connecting. Such an arrangement even requires less cabling from the computer than in figure 5, where the local network and the IONET channel are separated.

The preferred form in which this invention has been implemented is in connection with special electronic components and protocol used in a local area network known as ARCNET (trademark), which is a product of the patent applicant. However, there is no restriction that the present invention must be implemented with technology from the ARCNET local network. The present invention can be implemented with any type of local network of the signaling type. Nevertheless, the invention is described in connection with the preferred form that utilizes ARCNET technology for local area networks.

The hardware and software components at ARCNET are commercially available and well known. Of this, the patent applicant has published detailed information regarding its ARCNET local network, where i.a. The ARCNET Designer Handbook, copyright 1983, is available from the patent applicant. Furthermore, Standards Microsystems Corporation, 35 Marcus Boulevard, Hauppauge, New York 11788, has marketed two of the significant integrated circuits utilized in the ARCNET local area network and has additionally published substantial functional descriptions, enabling those skilled in these areas to build an ARCNET local area network. Such descriptions can be found in the Standard Microsystems Corporation data catalog, published in 1985, pages 193 to 213. Given the relatively well-known and appreciated nature of the ARCNET local area network, ARCNET features used in connection with the present invention will be described below in relatively abbreviated version.

The ARCNET local network is based on a telecast system. In a signaling system, any node in the network will wait to receive a unique short sequence of digital bits, i.e. signal known as a character, from a preceding node. Receiving a character indicates that the device at that node is allowed to send or receive information over the network. The network is designed to ensure that only a single character is present in the network at a time. After sending the information, the node passes the character on to the next logically successive node in the network where the procedure is repeated. If a node receives the token and has nothing to send, it forwards the token right away. The ARCNET local area network is arranged so that only active nodes are present in the network at any given time. In this way, nodes that are not active or not switched on are not logically or electrically involved in receiving and sending the character. The ARCNET network is able to reconfigure itself to accommodate nodes that join the network, and to eliminate nodes that drop out of the network by dynamically adjusting the addresses of the nodes to which the character is sent. Such changes in the activity state of the nodes may well occur while the network is running, without affecting the network above the link level.

The standard communication medium used for the ARCNET local area network is an RG-62 coaxial cable. The cable is designated 170 in Figure 2. Other communication media may include fiber optics, infrared connection over the ether, microwave connection and shielded twisted pair cable.

Connection options to the coaxial cable are simplified by using connection devices known as hubs. Each thread center contains several ports, to which medium interfaces known as resource interface modules ("Resource Interface Modules", "RIM") can be connected for the purpose of communicating with each processor, or to which other cable links can be connected. A "RIM" is present at each node. Wire centers act as active or passive repeaters between cable sections, and have no function in routing signals. A wire center simply retransmits any incoming signal to each of its outgoing ports as an outgoing signal. Wire centers have also been described in the published ARCNET local area network literature, and are also available for purchase on the commercial market.

The physical topology of the ARCNET local area network is like an unbounded tree. The logical configuration of the electrical connection in the ARCNET local network is like a bus where each individual transmitting node sends its signal to all other nodes in the network. The cabling in the ARCNET local network is bidirectional, i.e. signal flows alternatively in both directions over the cable. In medium access control terms, the ARCNET local area network is a logical ring based on arithmetically increasing values to identify the network's "RIM". The local area network automatically reconfigures itself to eliminate inactive nodes from the logical ring and to add newly active nodes to the logical ring, so that the character is sent from active node to active node based on the "RIM" identification number. No time is wasted transferring the character to nodes that are not active. The token can be transmitted from active node to active node without regard to the physical location or position of the node in the network. The character is sent between all the active nodes on the network before it returns to the original node, and thus follows a ring-like pattern.

The "RIMs" act as the physical interface means to the communication medium or cable 170, both in the present invention and in conventional ARCNET local area networks. One such "RIM", designated 178 is included within each distributed adapter 172 and in each computer system 100a suspended on the interconnect cable 170 as shown in Figures 6 and 7. Each "RIM" 178 includes a transmitter that transmits or broadcasts signals on a cable 170, many message buffers that receive and store messages or signals to be sent and received over the cable 170, as well as selection and other logic necessary to share the buffers between the processor the "RIM" is connected to, such as the microcomputer 180 shown in Figure 6, or the control processor 102 shown in Figure 7, and to perform its other functions. The "RIM" uses baseband signaling over the interconnect cable 170. The "RIM" 178 is a transformer coupled to the interconnect cable 170, which can be switched on and off while the local area network is operating, with minimal impact on network operation and no impact on reducing network performance when the "RIM" is turned off. Each "RIM" has its physical address, often referred to as "RIM ID". This address is used to carry out the character transmission.

In addition to the "RIM" 178, each distributed adapter 172 includes a microcomputer 180 and an interface device 182, as shown in Figure 6. The microcomputer 180 has sufficient computing capacity to handle the required data rate and implement the IONET channel communication and control protocol. Unlike prior art cluster controllers or other multi-port adapters, the microcomputer 170 does not include an operating system functionality, a local area network functionality, or any other multi-user functionality. A significant saving in administration and an increase in the network's bandwidth has thus been achieved, together with a considerable reduction in cost.

The microcomputer 180 can be better described as a microcontroller which simply contains a simple central unit CPU, a smaller ROM, and various input/output and timer functions on a single integrated circuit. The preferred form utilizes a Hitachi HD63B01YO microcomputer, which was chosen for cost effectiveness and space considerations. More information about this microcomputer can be found in Hitachi Microcomputer Data Book No. U71 from July 1985 on pages 358 to 405.

The device interface 182 of the distributed adapter 172 is specific to the particular type of I/O device 176 connected to the distributed adapter 172. As an example, the device interface 182 may be an RS-232 serial interface for connecting terminals and modems, an 8 -bit parallel interface for connecting inexpensive printers, an interface for connecting the most popular personal computers, or an 8-bit general "handshaking" interface for connecting various types of peripheral equipment.

The distributed adapter 172 can be built into any type of device as shown in Figure 2, or can be a separately connected box that is located physically close to the device. In all cases, the interconnection cable 170 is directly connected to the distributed adapter 172. Figure 7 illustrates the interconnection of a computer system 100a to a cable 170 at the IONET channel. The central processor 102 of the computer system is connected to the "RIM" 178, and the "RIM" is connected to the cable 170 at its node 174. By comparing Figures 6 and 7, it can be clearly understood that the function of the IONET in the central processor 102 is quite similar to the function of microcomputer 180, except that the central processor of the computer system does not directly work against the input/output devices. In other words, the central processor 102 supports the IONET protocol and communicates directly through the "RIM" over the cable 170, without requiring the use of separate protocols to achieve communication to and from channel controllers and multiport adapters as is common in older technology. Only the "RIM" is needed to work against computer systems on the cable, not the complete distributed adapter. If more than one IONET channel is used from a single computer system 100 (Figure 3), more than one "RIM" 178 is required. Figure 8 illustrates a representative distributed adapter 172a in greater detail. The adapter 172a sends serial data to, and receives serial data from, a conventional I/O

device 176a in RS-232 format.

The "RIM" 170 includes a hybrid circuit 190 that is electrically coupled to the interconnection medium or cable 170. The hybrid circuit 190 is a commercially available product and is available for sale from Centralab, Inc., 2601 South Moorland Road, P.O. Box 2145, Milwaukee, Wisconsin 53201; or from Micro Technologi, Inc., W141 N5984 Kaul Avenue, Menomonee Falls, Wisconsin 53051; or from Zenith CRT and Components Operations, 100 Milwaukee Avenue, Glenview, Illinois 60025. The hybrid circuit includes a transformer coupling. A clock oscillator 192 provides clock pulses to the transceiver 194. In addition to controlling the signal within the distributed adapter 174a, the clock circuit 192 also establishes synchronization with respect to bits of data present on cable 170. The transceiver 194 is a commercially available part supplied by Standard Microsystems Corporation and has the designation COM 9032. The transceiver 194 contains a transmitter that sends a signal to, and a receiver that receives a signal from the hybrid circuit 190. The transceiver 194 also provides clock pulses to the controller 196, and to the microcomputer 180 via the conductor 198.

The controller 196 is the heart of "RIM" 178. A number of switches 200 are connected to controller 196 which are used to establish the unique "RIM" identification number ("RIM ID"). "RIM ID" is synonymous with a node on the network where "RIM" 178 is connected. The controller 196 contains a microprogrammed sequencer and all the logic necessary to control character transmission over the network and to send and receive data packets at the correct time. The controller 196 also establishes the network configuration, and automatically reconfigures the network when new nodes are added or deleted from the network. The controller 196 also performs address decoding functions, cyclic redundancy check ("CRC") during packet generation and reception, and acknowledgment as well as other network functions. The controller 196 is commercially available from Standard Microsystems Corporation under the designation COM 9026.

A standard multiplexed address/data bus 202 emanates from the controller 196, and is the means that handles the interface for data and address communication. A unidirectional address driver 204 and a bidirectional data transceiver 206 may also be connected to bus 202 for the purpose of allowing microcomputer 100 to connect to this bus.

An external packet buffer, direct storage "RAM" 208 must comprise at least 2048 8-bit storage space, which is sufficient to store up to 8 complete IONET packets. Direct storage 208 can be accessed by both the controller 196 and the microcomputer 180. A buffer pointer 210 exists to identify which of the 8 storage locations for packets is to be used when sending packets, receiving packets, and processing packets by the microcomputer 180. The controller 196 provides all the necessary signal for access selection to direct storage buffer 208 between itself and the microcomputer 180. Direct storage 208 is a conventional digital memory product.

Microcomputer 180 contains the necessary memory and processing power to respond to the control information found within the IONET protocol, for communication purposes relating to control and data flow. The microcomputer 180 operates in conjunction with the controller 196 and the transceiver 194 by implementing a transmitter state machine and a receiver state machine. The transmitter state machine controls the transmission of signals from "RIM" 178 over cable 170. The receiver state machine controls the reception of signals from cable 170 to "RIM" 178. The information encoded in the transmitted signal and decoded from the received signal is stored in the aforementioned areas in the direct storage for packet buffer 208.

The microcomputer 180 includes a parallel I/O port 212 and a serial I/O port 214. The serial I/O port 214 is coupled to line drivers and receivers 216 to communicate with the I/O device 176a, in this case the distributed adapter 172a for RS-232 which is shown in Figure 8. For interfaces to other types of devices, the parallel port 212 can be used.

Having now described the general arrangement of components in the present invention, the following set of definitions can be better considered. These definitions relate to more particular characteristics of the present invention. A "server" is a processor that simultaneously supports multiple IONET sessions, which is the connection between its subaddresses and its internal functional entities that can be dynamically assigned at session initiation. A "client" is a distributed adapter or computer that supports one or more IONET sessions with fixed connections between its subaddresses and its internal functional entities. A "device" is an entity at one end of the two-way communication path of an IONET session. The terms "client" and "server" are used here as descriptive terms related to a typical usage pattern. Communication that makes use of the present invention can be established by any number of devices, either client and client, server and server, or client and server. A device is identified by an address, which is the "RIM ID" of the processor or distributed adapter associated with the device, and a subaddress, which is the means used to distinguish between source and destination devices for each individual packet at each single processor or distributed adapter, which can connect several devices simultaneously. A "node" refers to anything that connects to an IONET channel using a "RIM". A "session" is a point-to-point two-way virtual circuit established between a pair of devices. A session consists of two "half sessions". A half-session is the communication link between a transmitter at one node and the receiver of the corresponding session participant at the other node. There are two half sessions, one in each direction, for each full session that is established.

The signals sent over cable 170 control the communication over the network. These signals form an IONET protocol for communication and control over the IONET channel. The IONET protocol uses features from ARCNET local area network hardware, but the IONET protocol is not ARCNET specific. The IONET protocol can operate with comparable efficiency and identical functionality on any token-based network, but will possibly operate with reduced efficiency when selection techniques other than token transmission are used.

The preferred form of the interface to the network is limited only by the need to support the IONET protocol and as a boundary to the "LAN" medium used, such as e.g. ARCNET "LAN". The IONET protocol operates independently of any particular device or any particular operating system and independently of the characteristics of any of the input/output channels on the various computer systems.

The IONET protocol is a fully peer-to-peer protocol, existing on the network, transport and session layers of the International Standard Organization (ISO)'s Open System Interface (OSI) reference model for communication, which will be described below. There is no master-slave relationship between the communication entities in connecting, maintaining or using a session between two devices. This is in contrast to what is characteristic of virtually all input/output channels, where the channel controller at the host processor is the master and the fundamental controller of any communication over the channel. In the IONET protocol, there is no functional difference when it comes to control functions or the byte communication between any device, other than what can be seen as the special capabilities of these devices.

The OSI model shown in figure 9 can be used to describe communication systems, including networks. It is theoretically possible to replace the functionality of any of these layers with equivalent functionality implemented in a different way, and all the other layers will be unaffected, and will operate correctly in the system. The communication between an input/output device 176a and another input/output device 176b over the communication medium such as the cable 170 is described on the basis of the seven layers or levels, each of which involves a particular level of functionality within the communication protocol. The lowest level is physical layer 220.

The physical layer 220 involves the physical connection to the communication medium 170, and the physical signaling such as voltage level in an electrical system, optical modulation in a fiber optic system, and high frequency modulation in a microwave system, to take a few examples. In an electrical system, the physical layer is represented by bit streams that are present on the communication medium.

The next layer is the link layer 222, which is sometimes called the data link layer. The data link layer 222 is the layer where the physical delivery of raw data between nodes on the network is carried out. The physical signaling protocol, including link information, synchronization information, error correction information, block sizes, etc. is handled in this layer. In most networks, the data link layer 222 is the layer where the fundamental communication errors can be detected and either corrected, or retransmission is requested. Communication between a pair of nodes depends on compatible implementations of the data link layers. In summary, it can be said that the data link layer establishes, maintains and releases data links, and is used for error detection and physical flow control.

The third layer is the network layer 224. The network layer 224 takes care of information routing through the network, including addressing, network initiation, error detection and correction, as well as switching, segmentation and blocking of the information. Sometimes receipt of deliveries of raw data is done at the network level, and sometimes at the data link level.

An aspect of communication that is not directly affected by the OSI model at an explicit layer refers to the means used for logical selection of the right to transmit at the physical layer. OSI would normally place this selection at link layer 222, but it is sometimes placed elsewhere. As far as this analysis is concerned, media access control is intended to be a function for the link layer.

The next layer is the transport layer 226. The transport layer refers to the transparent transfer of data, end-to-end control, multiplexing, imaging and the like. Data deliveries require reliable deliveries, as opposed to a best effort to deliver the data that must be taken into account in the layers below the transport layer. At the transport layer, it is assumed that data has been delivered in a reliable manner, and such things as retransmission of missing data, keeping track of data delivered out of turn, correcting transmission errors, etc. have been corrected at or below the transport layer. As an effect of this, data entering and exiting the transport layer 226 and in the higher layers is data that is meaningful to the computer system, as opposed to raw data formatted for the network.

The fifth layer is the session layer 228. The session layer 228 uses the delivery of data from the transport layer to group pieces of data belonging to a given activity called a session. Sessions take place between two entities at different locations on the network. At any given time, single nodes on the network may be involved in multiple sessions going to multiple nodes, and many sessions may be multiplexed over the same network. Nevertheless, the services in the session layer are intended for end-to-end deliveries of data that belong to a given logical activity, without mixing in data from other activities.

Layer six is the presentation layer 230. The presentation layer 230 is the interface between the session layer 228 and the application layer 232 at level seven. The application layer 232 is the layer where the actual data is provided to, or received from, the input/output device 176 at each end of the communication. The presentation layer 230 shall mainly present data in an acceptable form that can be used in the application layer 232 without making any compromise with respect to the session layer 228's network-related integrity. The presentation layer 230 therefore relates to data interpretation, format and code information, while the application layer relates to the user's application processes and management functions.

The activities for both the local area network and IONET channel functionalities discussed below exist at the session layer and down. No further discussions have been included regarding the presentation and application layers, as these layers are strictly specific to the system, the physical device and/or the user application.

The byte arrangement of an IONET data packet 240 is illustrated in Figure 10, and in Figure 11 the IONET packet is broken down into the hierarchical levels corresponding to the OSI model illustrated in Figure 9. Not included in the IONET packet is a notification interrupt 242 which is generated in a "RIM" of the controller 196 see Figure 8, to identify the start of a packet. The notification interrupt 242 consists of six sequential "1" bits, and is found at the physical level as shown in Figure 11. The remaining part of the information in the packet at physical level 244 is a set of bytes to eight bits, which contains link layer information 245.

In the packet from the link layer 245, "RIM" sends a Start Of Heading ("SOH") byte, which is a character marking the start of an ARCNET data packet. After the "SOH" byte 246, the "RIM" sends a source identification ("Source Identification", "SID") indicating the "RIM ID" of the node sending the packet. The two following bytes are repetitions of the destination identification ("DID") byte 250. The "DID" byte 250 indicates the "RIM ID" of the node to which this packet is addressed. The "DID" byte exists twice for error control and reliability purposes in an ARCNET local area network. The next following byte 252 is coded to identify the length of the packet number of network level bytes, and is generally referred to in ARCNET terminology as the Continuation Pointer ("CP"). The final two bytes of this packet are a 16-bit Cyclic Redundancy Check ("CRC") 254. The "CRC" byte is generated by the "RIM" to detect transmission errors.

The "SOH" 246 at the start and the "CRC" 254 at the end of the link layer packet 245 are not normally considered part of the ARCNET packet, because they are both generated by and checked by the network hardware interface, i.e., the ARCNET controller 196, and will never occur in the packet buffer (RAM 208, figure 8) of the "RIM". The other bytes in the header in the link layer packet 245 are found in the packet buffer, even if the network's hardware provides "SID" 248 for outgoing packets regardless of the value in the packet buffer. The "DID" of each receiver will always be equal to the "RIM ID" or will be zero for broadcast packets received by all nodes. Furthermore, only one of the two remains

"DID" stored in the "RIM"'s packet buffer so that only one "DID" 250 is part of the ARCNET header portion 258 of the IONET packet 240. The IONET packet 240 shown in Figure 10 follows this convention for illustration.

Normally, a typical ARCNET packet is 256 bytes, or less in length. However, it is possible to communicate over the ARCNET local network with long data packets of up to 512 bytes. In long data packet mode, "CP" is 252 two bytes long, making the link layer header six bytes long rather than five as shown.

The network layer information 257 which is after "CP" 252 and before "CRC" 254 is information sent from the controller 196 (Figure 8) up to the network layer's interpretation using low-level software or firmware associated with the computer system or the distributed adapter.

The network packet 257 starts with a seven-byte long header with the byte for the system code ("System Code", "SC") 256. The "SC" byte 256 is a common characteristic of all ARCNET packets and indicates the type of packet. The system code is used to identify and distinguish different types of communication protocols that can be used at the same time.

When the "SC" 256 in the ARCNET header identifies an IONET packet through the unique IONET packet code, the following ten bytes 260 form the IONET header for the IONET packet 240. The IONET header 260 provides network level and transport level information and indicates how the remaining data area 262 is to be divided between administrative information 264 and byte stream information 266.

The division of the data area 262 into an administrative portion 264 and a byte stream portion 266 allows what is called "out-of-band" signaling, by separating the administrative information used to control the I/O device or distributed adapter or report status from the I/O device or distributed adapter, from the byte stream information 266 used to communicate information to and from the I/O device. The administrative information 264 may be provided by, inspected by, or modified by IONET-controlled components, but the byte stream information 266 is always handled in a transparent manner, and is therefore delivered to the receiver's I/O device unmodified from the source value that was there when it was sent.

The first six bytes of the IONET header 260 are part of the network packet 257. These bytes are in order a transmitter status byte ("Transmitter Status Byte", "TXSB") 268, a receiver status byte ("Receiver Status Byte", "RXSB" ) 270, a two-byte source subaddress "Source Subaddress", "SSA" 272, a two-byte destination subaddress ("Destination Subaddress", "DSA") 274, the remaining four bytes of the IONET header 260 are contained within the transport level packet 276. the first byte in the transport level packet indicates the packet function ("Packet Function", "PFN") 278. The following byte 280 is not yet in use, but is reserved for future extensions. The third byte is an administrative length value ("Administrative Length Value", "ADL" or "ADLNG") 282. "ADL" has the function of identifying the length of the administrative information 264 of the data area 262. The last byte 284 is a byte stream length value ("Byte Stream Length Value", "BSL" or "BSLNG") 284. "BSL" identifies the length of the byte stream 266 of the data area 262. Both "ADL" 282 and "BSL" 284 for the aggregate length of the administrative information 264 and the byte stream information 266 may be less than the total length of the network level packet 257. In such cases, the remaining bytes in the network level packet 257 beyond those defined for the data area 262 are not in use. The length of the data area 262 can be up to 242 bytes in short packet mode or up to 497 bytes in long packet mode. When long packets are used, the "CP" 252 is two bytes long and both the ARCNET header 258 and the IONET header 260 are extended by an additional byte more than what is illustrated in Figure 10.

More details regarding ARCNET header 258 and IONET header 260 are illustrated by the diagram shown in Figure 12, which shows the name of each field within each header, the bitwise arrangement from the least significant bit on the right to the most significant bit on the left in each fields, and provides a summary for each field.

The source identification ("SID") of each field in the ARCNET header 258 for each incoming packet is checked against the "RIM" at each node each time a session is in progress. All packets sent by the active session partner are accepted for interpretation and processing. All packets received from the "RIMs" from other nodes, except those containing special functions regarding level control, are rejected, and the "RIM" receiver is immediately made ready again. When no session is in progress, all incoming packets will be interpreted, but only those containing special network and transport level control functions related to the establishment of a session and setup parameters or statistics will be accepted for processing.

The receiver identification ("DID") 250 in the ARCNET header 258 is either equal to the "RIM ID" of this node, or is zero for broadcast messages. The "RIM" using the IONET channel is always configured to receive broadcast messages. Only local commands, described below, are accepted as broadcast by devices. Any other broadcast messages received, even if they have IONET system code ("SC"), will be rejected by the device.

The continuation pointer, ("CP") 252 in the ARCNET header is used to determine the length of an IONET packet. "CP" is one byte long for short packet mode, and contains the packet length subtracted from 259. "CP" is two bytes long, with the first byte set to zero, and the second byte set to packet length subtracted from 516 for long packet mode.

The system code ("SC") 256 of the ARCNET header 258 may be any special code identifying the IONET protocol, and example of such coding is illustrated in Figure 12. Incoming packets with other system codes (other than a diagnostic system code) are rejected by all clients and if they are opposed, this happens by all the servers and by other protocol codes.

The IONET header 260 is used by all transmitter and receiver state machines to control the byte stream communication over the network communication medium, to direct packet contents to the correct I/O device, and to determine the contents of the data area 262 of the packet.

Sender Status Byte ("TXSB") 268 in the IONET header 260 contains information related to the general use of the IONET packet and the status of the sender that sent the packet. As shown in Figure 12, the immediate field in the "TXSB" byte is coded to distinguish between packets of immediate priority (the field =1) and packets of normal priority (the field=0). Packages for expedited delivery are referred to as immediate packages. Outgoing immediate packets are sent before pending normal priority packets, and incoming immediate packets will be processed as soon as they are received, before normal priority packets waiting in the receive buffer and (typically) before the rest of the normal priority packets in transit (if any) when the immediate packages are countered.

The operation field at "TXSB" contains a code for which use the IONET package will make of the transport level. The uses of the transport level that can be coded in the operation field are: "NOP", used for keep-alive messages; "IDLE", indicating a transmitter waiting ("Transmitter Waiting", "TW") status; "DATF", which indicates a transmitter active ("Transmitter Active", "TA") or immediate transmitter active ("Immediate Transmitter Active", "ITA") status on the last (or only) packet in the transmission group, where " The PFN" 278 field controls the use of the data area; "DATAI", indicating a "TA" status on first, or immediate packets in the transmitter group, where the "PFN" 278 field controls the use of the data area; "CONTROL COMMAND" which is further encoded in the function field of the "TXSB" byte.

The sequence number or function field in "TXSB" byte 268 contains the sequence number of the packet sent when the operation field is coded for all functions except the "CONTROL COMMAND" and "CONTROL REPLY" functions. When the operation field is coded for "CONTROL COMMAND" and "CONTROL REPLY", the control function is coded in the function field at "TXSB" as shown in the following diagram:

Referring to the above diagram, a "CONTROL COMMAND" is present in the operation field at "TXSB" 268 when the "TXSB" value starts with "E" or "6" on the diagram. The function achieved by the special "CONTROL COMMAND" is indicated in the "CONTROL FUNCTION" column. Data functions encoded in the operation field at "TXSB" are indicated by values beginning with "4", "5" or "C". These four functions, terminating data transfer ("DATAF"), initiating/intermediate data transfer ("DATAI"), "flush" buffers, run extended diagnostics, and report status, are encoded in the type code field at "PFN" byte 278 in addition to "TXSB". The "LNG" field shows the length required or allowed for each type of control function. Column "received by" indicates the class of device, Either client ("C"), server ("S") or both ("A"), which can receive each type of IONET packet. The "SESSION." column indicates whether a command is accepted both inside and outside a session indicated by "E", or whether the command is accepted only outside a session, indicated by "O", or whether the command is accepted only inside a session, indicated by a "IN". The "MOD." column indicates whether the packet must be sent as an immediate packet, indicated by an "I", whether the packet must be sent As normal priority, indicated by an "N", or whether the packet can be sent in either normal or immediate mode, indicated by an "E". In the case of virtually all control commands, a response packet is generated by the receiving device and is sent back to the device that sent the original control command. The "TXSB", "PFN", and "LNG" columns under "RESPONSE" provide control codes and lengths of control response functions sent in response to the various control commands.

Receiver status byte "RXSB" 270 in the IONET header contains information relating to the status of the receiver state machine at the device that sent the packet. The highest order bit or immediate field is set to distinguish between acknowledgment of immediate packets and normal packets. The acknowledgment field ("Acknow-ledge", "ACK") encodes acknowledgment of the last packet received by the device such as "NOP"; "BUSY", indicating a receiver waiting ("Receiver Waiting", "RW"); or an immediate receiver waiting ("Immediate Receicer Waiting", "IRW") status; and "READY", indicating a receiver active ("Revceiver Active", "RA") or an immediate receiver active ("Immediate Receiver Active", "IRA"). The error field is set equal to "1" if a detectable internal error locally in the client's hardware or firmware has occurred, and is otherwise set to zero. The sequence number field contains the sequence number of the package that is being acknowledged.

The source subaddress ("SSA") 272 of the IONET header identifies the particular source device at the node from which the packet is sent. Receiver subaddress ("DSA") 274 identifies a particular receiver device at the node that is to receive this packet.

The packet function "PFN" 278 defines the use of the data area 262 (figure 10) in the IONET packet in those cases "TXSB" indicates that it is a "data" packet by an operation code "DATAI" or "DATAF". The "PFN" type code field 278 generally encodes use of the packet to indicate data transfer, when the data area contains byte stream and administrative data to be used by the I/O device; or a client control command, when the data area contains control information used by the client's firmware; or a client control response, when the data area contains control information sent in response to a control request.

The bits named "ASL" and "ADL" at "PFN" 278 are used to store the most significant bits of the value of the length of the "ADLNG" 282 and "BSLNG" 284 bytes described below. The function code field at "PFN" 278 is always set to zero for data transmission functions. For client control commands and client control responses, the client function is coded to indicate "flush" the buffers, run extended diagnostics, and functions to report status previously identified in the above diagram.

The bytes for the address length ("ADLNG") 282 and the byte stream length ("BSLNG") 284 form a data area description. The data descriptor defines the use of the data area 262 (Figure 10) of the IONET packet. The value within the "ADLNG" field 282 specifies the length of the administrative information 264 (Figure 10). If the administrative information has a length other than zero, the byte stream area starts immediately after the data descriptors 282 and 284 and extends the specified number of bytes. Bit 4 of the "PFN" byte 278 acts as the most significant bit of the "ADLNG" byte 282 to allow "ADLNG" values above 255 for use in long packet mode.

The number encoded in the "BSLNG" field 284 specifies the length of the byte stream 266 of the data area 262. If the value in "BSLNG" is non-zero, the byte stream area starts from the byte after the administrative area, or follows the data area descriptor 282 and 284 if the "ADLNG" field 282 is null. The byte stream extends the number of bytes specified in field 284. Bit 5 of "PFN" byte 278 serves as the most significant bit of the length value specified in "BSLNG" field 284 to accommodate "BSLNG" values larger than 255 for use in long packet mode.

The most common packets sent over the IONET channel are those that transfer bytestream data for use by the receiver's I/O device. Control function packets are those whose content is interpreted within support software or firmware at the IONET server or IONET client, and is not sent by the input/output device. IONET's control function packages are those identified in the diagram above and are identified in "TXSB" 268, as described in connection with figure 12.

IONET's control function commands and responses are available at several levels. The network level control functions relate to nodes on the IONET channel and are independent of the session activity. The transport level's control functions are used to establish, manage and terminate sessions. The session level control functions are used to control the interface to the I/O devices, and are only usable when a session is in progress, with the exceptions noted. Session level byte stream functions transfer data, control and status information to and from the connected I/O devices.

Control command messages are always sent using short IONET packets. All "CONTROL COMMANDS" require the relevant recipient to send back a "CONTROL REPLY". In other words, control functions entail a special "handshake" between the transmitter state machines of the communicating devices. This "handshake" does not involve the receiver state machines. The generalized details applicable to each "CONTROL COMMAND" and "CONTROL REPLY" follow below.

The positive acknowledgment of a "CONTROL COMMAND" in the form of a "CONTROL REPLY" is always required, regardless of the sending package number. No further transmissions (except retries) are made until the corresponding "CONTROL REPLY" is received. Sequence numbering is neither required nor used for control function packets. Examples of types of terminating codes that are encoded into the administrative area 264 of the data area 262 of each IONET packet 240 that sends the control response can include be as follows: successful completion of the control function; the control function is not supported by the receiving device; the control function is rejected due to the recipient's status; the control function is rejected because the device is not in session; the control function is rejected because the device is already in session; the control function is rejected because the device configuration lock is set; and there are specification errors in "CONTROL COMMAND" parameters.

As shown in the preceding diagram, the network level control functions also include report device parameters, report statistics, report interface parameters, set device parameters, set interface parameters, and locate. There is also a null function, not shown in the diagram above, which is ignored by the receiver without generating either an error or a response. These network level control functions are accepted by IONET's nodes at all times, whether a session is in progress or not. These control functions do not need to originate from the "SID" of the active session partner to be accepted during a session.

"CONTROL COMMAND" for reporting device parameters causes the IONET device to generate a "CONTROL REPLY" packet containing information about the type and status of the input/output device. The command for reports

device parameters are recognized by all devices, and are accepted whether a session is in progress or not, and are accepted from any source if the device is in a session, and not just from the session partner. Some of the information reported relates to the attributes of the node. This information is reported on an equal basis for all facilities. The command report device parameters is not accepted from broadcast packets due to the large amount of traffic that would then be generated, the lack of broadcast capabilities referring to subaddresses, the lack of ability to determine if a response has been received from devices. The report device parameters command is sent as an immediate packet.

The format of the packet for the "CONTROL REPLY" that is sent in response to a "CONTROL COMMAND" to report device parameters can be advantageously

included in the administrative information section 264 of the data area 262 (Figure 10): an indication of the termination code described above, type code used to identify clients and acquirers and the type code of the input/output interface 182 (Figure 6) associated with the device, a packet length, the transmit packet number , indicating the maximum number of "DATAI" packets that can be sent before a "DATAF" packet is required, and a session initiation type byte. The session initiation type byte indicates a restriction on an IONET device that limits its communication to predetermined clients and servers in a predetermined session. This type of restriction on communication is advantageously included with the intention of limiting access to special devices and requiring special security levels to achieve communication between special devices.

The control command report statistics causes the device to which the command is addressed to generate a "CONTROL REPLY" packet containing statistical information collected by the device. This command is recognized by all nodes at subaddress zero, and can be recognized by all devices. This command is accepted whether a session is in progress or not, and is accepted from any node when the device is in session, not just from the session partner. Some of the information that is reported relates to attributes relating to the node, and is reported in the same form for all devices on the node. This command is not accepted from broadcast packets due to the large network traffic that is then generated, the lack of broadcast capabilities that refer to subaddresses, and the lack of ability to determine whether all responses have been received. This command is sent as an immediate packet.

"CONTROL COMMAND" reports interface parameters, causing the client device to generate a "CONTROL REPLY" packet containing information about interface status, and corresponding modal status of the device. The information is reported from the parameter set stored in the direct storage which is associated with the device, and which is in use by the device at the time. These values may in special cases be different from the values stored in

the client's non-volatile stock. This command is recognized by all clients in a way specific to each client, is rejected by all servers, is accepted by clients whether a session is in progress or not, and is accepted from any source when a session is in progress, and not only from the session partner.

The command for report interface parameters must be sent as an immediate packet for everyone other than the session partner, and can be sent in either immediate or normal mode by the session partner. Special bytes in the administrative information area 264 of the data area 262 (figure 10) of the IONET package can be set aside for communication values that are different from the parameters stored in the direct storage.

"CONTROL COMMAND" set device parameters cause the client to store new values in the non-volatile storage. This command is only accepted by client devices and only when the configuration lock is not set, and is then accepted from any source, not just the session partner (if any). This command must be sent as an immediate packet.

In addition to the aforementioned information within the administrative information section of the data area of the IONET packet, there may be bytes to identify the type of external device, a device name, the type of device that initiated the session, the device type-specific class of service, the identification of a predetermined partner or remote session password, as well as the status of the configuration lock.

"CONTROL COMMAND" set interface parameters causes the client to set new values for interface control and corresponding modal status. The new values are applied to the interface, and are stored in the client's direct storage. These values can

also stored in the client's non-volatile storage. This command can also be used to retrieve values from the non-volatile storage into the direct storage.

The set interface parameters command is recognized by all clients in a device-specific way, is rejected by all servers, is always accepted by clients from the session partner, and is accepted by clients from any source whether in a session or not, if the configuration lock is not set.

The set interface parameters command must be sent as an immediate packet for anyone other than the session partner, and may be sent in either immediate or normal mode by the session partner. Additional information in the administrative information section of the IONET package relates to control from direct storage or non-volatile storage to write parameters from the package into direct storage or into both direct storage and non-volatile storage and to retrieve parameters from non-volatile warehouse and into direct storage. Other information in the administrative information section relates to device parameters that are type-specific.

The "CONTROL COMMAND" locate may be sent as a broadcast message by devices attempting to establish a session for the purpose of determining the "RIM" identification number and subaddress of a desired receiving device that is attempting to locate using the name it has been assigned. If multiple responses are received, all but the first are ignored. The locate command is recognized by all nodes with subaddress zero, is accepted whether a session is in progress or not, is accepted from any source when the device is in a session, and not just from the session partner. The locate command is the only control command function that is accepted from broadcast packets.

A locate command must be sent to subaddress zero at the receiver. The source subaddress in the control response packet identifies the particular device on the responding node that has been located by sending its identification number. If multiple devices at the responding node match the name, multiple response packets are generated. If no devices at the nodes receiving the location packet match the name, no response is generated.

The fact that a time interval expires while waiting for a response to a locate command indicates that no active device exists that has a matching name. The locate command must be sent as an immediate packet. The name of the responding packet is encoded into the administrative information section of the IONET packet. The locate command also contains a desired service class. If the value is null, then only the name must be equal, otherwise both name and service class must be equal. The termination code in the response to a location command distinguishes between the case where the device is able to accept a connection command for the specified service class, and the case that the device is not able to accept such a connection command.

As shown in the diagram above, the transport level control commands include connect, forward, disconnect, redirect and resynchronize.

The "CONTROL COMMAND" for connection establishes a session, if none is already in progress and is rejected if received when a session is already in progress. Either client or server can initiate the session by sending the connect command. Connection requests to servers should generally be sent to the subaddress that is returned as a response

to a locate command after the desired session partner's name (or to subaddress zero). The server may redirect the session communication to another subaddress by sending the appropriate value for the source subaddress ("SSA") 272 (Figure 12) field in the response packet. The session traffic must then be directed to the recipient subaddress received from the "SSA" field in the response packet.

The connection command must be sent as an immediate packet. Preferably, the administrative information section of the "CONTROL COMMAND" packet for connection should contain information regarding the type of device, its hardware and firmware or software revision number, the version of the protocol it offers, its maximum subaddress, its packet length and counter of packets sent, its minimum received length of packets, the time before a packet must be sent by a client, type of external equipment for the source, a device name for the source, session initiation type for the source, class of service for the source, and password for the session initiation.

If the connect command is accepted, a "CONTROL REPLY" packet will be generated whether the connect request is successful or not. If the termination code field indicates that the session was not successfully established, the termination code will specify the reason for the failure. Some of the reasons that can be specified in the exit code for failure to successfully establish the session are the control function has been rejected because the device is already in a session, there is a specification error in the control function's parameters, the responding device does not support the particular protocol version or hardware revision number or revision number for firmware or software requested, the device is of unavailable class of service, the device is not configured for remote initiation, or there may be an incorrect password or name. In addition, the other administrative information in the "CONTROL REPLY" packet can relate to which protocol version is to be used, the packet length to be used, the counter for sent packets to be used, the maximum length of incoming packets, and to the time before an incoming packet must be sent .

"CONTROL COMMAND" forward configures a server device to be a forwarder of packets for linking between networks. Once the forwarding is established, the device will neither interpret nor acknowledge IONET packets, but simply forwards them with the intention of creating an intermediary link. Since it is not possible to communicate with a forwarding device, all configurations of this device must be done before sending the forwarding command. It

forwarding device does not operate state machines for transport control, but monitors the reverse channel to look for a "CONTROL REPLY" for disconnection to know when forwarding should end. To avoid loss of resources when communication is lost in an irregular manner, forwarding will be disconnected, and the device will enter a disconnected state, if no communication has been received in any direction after a time interval specified in the forwarding command that established the connection.

Requests for forwarding should generally be sent to subaddress zero. The forwarder can redirect the communication to another subaddress by setting a suitable value in the "SSA" field 272 (Figure 12) of the response packet. The communication will then later be routed to the recipient subaddress obtained from the "SSA" field in the response packet.

The forwarding command is rejected if received when a session is in progress. Devices that are not capable of acting as packet forwarders (includes all clients) will always reject this command. Either clients or servers can initiate forwarding by sending a forwarding command. The forwarding command must be sent as an immediate packet. The administrative information section of the IONET forwarding packet preferably includes the name of the receiving network, the name of the desired device on the receiving side, the desired class of services, and the communication deadlines.

The receiving device for the forwarded command performs a locate function on the desired network according to the indicated receiving device to determine the "RIM ID" and subaddress to which the communication is to be forwarded.

If the forwarding command is accepted, a response packet is generated whether the forwarding request is successful or not. If the termination code field contains any code indicating that the relay has not been successfully established, the termination code will specify the reason for the failure. The reasons for the error may be the same as those previously described.

A disconnect "CONTROL COMMAND" terminates a session. The disconnect command is rejected if no session is in progress. Both clients and servers can initiate a disconnect command. The disconnect command must be sent as an immediate packet.

A "CONTROL COMMAND" for redirection is sent simultaneously to the session partners of two active sessions from a node that wants to redirect the traffic to these two sessions so that the partners in these two sessions communicate with each other, and no longer with the node that sends the redirection command. This command must be sent as an immediate packet. The administrative information section of the redirect packet includes the new recipient identification, and the new recipient's subaddress. Ending a redirect command involves

resynchronization, as described below.

A "CONTROL COMMAND" for resynchronization causes the sender and receiver state machines at each end of a session to reset their state upon session establishment. This opens up the possibility that communication can be re-established without disconnection and reconnection in cases where the sequence number or other synchronization between the two has been lost.

Either clients or servers can send resynchronization command when a session is in progress. The resynchronization command is rejected if no session is in progress. The resync command must be sent as an immediate packet. The session-level control functions include "flush" buffers, run extended diagnostics, and report status. The session-level control functions are interpreted as the client's interface control in firmware. The details of most of these commands are type-specific, and only their common aspects are discussed below. Note that these session-level control functions are sent in packets such as where the "TXSB" value indicates data transfers ("DATAF"), but the value of "PFN" indicates client control requests and client control responses.

The "flush" buffer control function causes the receiver to discard all packets or parts of packets present in the receiver buffer within the distributed adapter, or low-level software. The command "flush" buffer is accepted by any device that has a session in progress, and is ignored when no session is in progress. The "flush" buffer command is sent as an immediate packet.

The control function run extended diagnostics causes the device to perform a diagnostic function and report the result of these. These diagnostic functions may be identical to those always run at startup, or may be extended or special tests. This command is recognized by all clients in a way that is specific to that type. Clients that do not implement extended diagnostics capabilities report successful completion of this command. This command is recognized by all clients, is rejected by all servers, and is only accepted when a session is in progress. The command run extended diagnostics can be sent either in immediate or normal packet. The administrative information section in the IONET command can include information about diagnostic parameters, and the administrative information section in the IONET response packet can contain information about the results of the diagnosis.

The report ststus control function causes the device to generate a response packet containing information about the ststus to the input/output interface for the device. This command is recognized by all clients in a way specific to that type. The command is rejected if no session is in progress. The command can be sent either as a normal or as an immediate packet. The minimum response in the IONET response packet consists of standardized interface control and status discussed below in the context of the session-level byte-stream functions.

The session-level byte-stream functions include "DATAI", to transmit initial or intermediate data packets: "DATAF" to transmit termination or simple data packets; "IDLE" to place the receiver state machine in a stop state; and "NOP" for messages that keep communication alive. The use of these functions is discussed below in connection with transport control's state machines.

The administrative information part of the data area of "DATAF and "DATAF" IONET packages is used to standardize interface control and status facility. The advantage of standardized interface control and status facility is that it provides means for direct access to device control and status information in a way that is independent of the physical interface to the type of I/O device The fact that the I/O device is type-independent allows a simple implementation of low-level software at a server to communicate with and control virtually any type of I/O device.

The administrative data area of the "DATAI" and "DATAF" IONET packets is used to hold an input status word ("Input Status Word", "ISW") which reports the status of the input external interface control signals and provides an indication of the general flow of /on and general ready/not ready status; a status mask word ("Status Mask Word", "SMW") which selects which input status changes are of interest to the session partner and should result in reporting in the administrative data part; and an output control word ("Output Control Word","OCW") which specifies the setup of the external interface output control signal.

All "DATAI" and DATAF" packets used for data transfer are used as follows: If the administrative data portion is zero, there is no change in interface control or status; if there are exactly two bytes of administrative data, these are "ISW ", if there are exactly four bytes, these are "ISW" followed by "SMW", if there are exactly six bytes of administrative data, these are respectively "ISW", "SMW", and "OCW", and if there are more than six bit bits, the first six are "ISW", "SMW", and "OCW", while the other bytes are type-specific. To give the possibility of reporting and setting information in later words without affecting the information in the output word, the most significant bit of each "ISW", "SMW" and "OCW" is a validation bit. A word with the validation bit set to zero is ignored. For communication from clients to servers, the "ISW" external interface control reports its input status , "SMW" reports the current mask setting, and "ISW" reports the external interface check its output status. For communication from servers to clients, "ISW" is not used, "SMW" is used to set the mask value, and "ISW" sets outputs for the external interface control. For server-to-server communication, "ISW", "SMW" and "OCW" are generally not used, and for client-to-client communication, these words are generally not used.

A strategy available from the present invention to achieve session-level security for data message communication is based on the use of the "SID" to prevent a third device from interfering with the communication between a pair of devices participating in an IONET session. When a session is in progress, Data and Control packets are only accepted if their "SID" matches the "SID" of the node that sent the original Connect Function packet, or that sent the response to the original Connect packet. In addition to being very simple and efficient to implement and requiring no additional hardware, this security technique provides a barrier against unauthorized communication from the other nodes. This occurs due to ARCNET link level hardware preventing the transmission of a "SID" other than its established "SID".

Sessions can be established and controlled using passwords and configuration locks. A password is special information established in the storage of a device. In order to establish a session, the connection command packet must originate from a device that has a "SID" corresponding to the password, or is within a group of "SIDs" defined by the password. All clints maintain special facility meters in non-volatile storage. The contents of this non-volatile storage can be accessed and updated by IONET control functions unless a configuration switch is set by another IONET control function. Once the configuration lock is set, it is not possible to make any changes to the non-volatile storage until the configuration lock is removed by human intervention on the device, e.g. operate a switch. Setting the configuration lock allows the device's configuration from being modified without authorization.

Clients can be configured for remote session initiation, in which case a server must initiate the session. By protecting the configuration information files at the relevant servers, users can be prevented from changing the location and/or characteristics of the process that will initiate the session. Clients can be configured for predetermined session initiation, in which case the session partner is identified and fixed in non-volatile storage at the client. The configuration lock is set to prevent the user and application software from changing the session initiation type and session partner. Because clients configured for predetermined sessions do not accept messages or session partner identification from the user, predetermined sessions allow for a direct, dedicated connection between a single server and a single client despite the multi-context and multiplexed nature of the communication medium. This form of dedicated point-to-point communication on a multiplexed medium is not typically available on conventional input/output channels except through the use of dedicated point-to-point single cable. Requests for remote session initiation received at any device may require a password if the type of session initiation is not defined in advance, thereby allowing devices to be configured to prevent unauthorized access. In the case of distributed adapters, the remote password cannot be read or modified if the configuration lock is set.

The state machine for state control operates to provide the functionality necessary to communicate over the IONET communication channel, and operate in response to the IONET protocol as described above. The communication is a two-way logical link, at the session level, between pairs of communicating devices. Each logic link involves two transmitters and two receivers, each of which is controlled by a simple state machine. Each session has an instance of both the sender and receiver state machine operating at each node participating in the session.

The purpose of the state machine is to synchronize the delivery of bytes, acknowledge successful receipt of packets, detect and retransmit missing or lost packets, detect and ignore duplicate packets, provide periodic "keep-alive" packets during periods when no data is being transmitted, provide flow control to prevent transmission of packets for which no receiver buffer is available, and avoids unnecessary flow control activities by stopping communication during periods when there is no data to send and/or buffer space to receive data, then restarting communication when these conditions are again present.

"TXSB" in the IONET header communicates the state of the sending state machine that sends the packet to the receiving state machine that will receive the packet. "RXSB" communicates the state of the receiving state machine at the device sending this packet (not the receiving state machine receiving the packet) to the sending state machine at the device that is

recipient of this packet (not the sending state machine sending this packet).

Acknowledgment for each packet is available as "RXSB" in the next packet sent by that sender at the device that received the packet for which it is acknowledged. During periods of bidirectional communication, this pending receipt will take care of the network's bandwidth. During periods of unidirectional communication, there will be no packets going in the opposite direction, however packets containing acknowledgment will be generated. When either the sending state machine or the receiving state machine has a state change to report, a packet is sent. If one of the state machines has nothing to send at that time, it reports no status using a "NOP" code in the status byte.

Counter for the maximum number of packets being established between session partners at the same time as the session itself is being established. These counters, which need not be the same for the two directions of communication, specify the maximum number of data packets that the sender can send without an acknowledgment from the receiver. (Command packets are always sent one at a time with replies for each command.) The sender must keep copies of the entire group of data packets until acknowledgment is received to keep the possibility of retransmission open. If an error in reception or synchronization occurs, this status will be reported immediately. Immediate data packets and all command packets are acknowledged upon receipt, regardless of the transmitter packet counter. Packages with normal priority can be designated to generate positive receipts. The receiver must have a sufficient number of buffers to take care of the maximum number of unacknowledged packets before indicating to the sender that it is ready for reception.

Normal value for send packet counter is one packet, which results in positive acknowledgment for each packet sent. The highest allowed packet counter value is 15, and is limited to the use of a number of four bits to maintain the synchronization of the packet deliveries. The transmitter packet counter used by any device should not exceed a value less than the number of packets the associated receiver state machine can hold without having to disconnect the "RIM" receiver. The higher the sender packet counter, the less bandwidth on the network and the less processing time used to send receipts, and the less time must pass between successive transmissions; but a larger number of buffers must be provided by the transmitter state machine to handle the possible need for retransmission.

Operation for transmitter and receiver state machines is relatively easy to implement in either hardware or software. Software implementation is preferred due to economics, and because hardware implementation would result in an unacceptably large physical size for the distributed adapter, for most applications. Figs 13 and 14 show the general state transition with respect to which criteria move the transmitter and receiver state machines between their states. The criterion that causes the state machine to remain in the same state is characterized by either complete determination based on received information as shown in the following state change tables in figures 15, 16, 17 and 18 or by receiving packets that are outside the protocol and therefore ignored and leaves the machine in the same status same condition. Fig. 13 shows the five basic states for the transmitter: Transmitter active ("Transmitter Active", "TA") When the transmitter has information to send and is in the process of sending or attempting to send; transmitter waiting ("Transmitter Waiting", "TW") when the transmitter is able to send data in terms of flow control, but has nothing to send, and therefore waits for the internal conditions within its node to provide more data; transmitter stopped ("Transmitter Stopped", "TS"), indicating that the transmission has been stopped due to transport level flow control, that is, a busy indication from the receiver state machine at the opposite end of the session; immediate mode transmitter active ("Immediate Mode Transmitter Activ", "ITA") changed from a normal mode when there is an immediate packet to be transmitted; and immediate mode transmitter stopped ("Immediate Mode Transmitter Stopped", "ITS") which is equivalent to "TS" but occurs due to transport flow control when in immediate mode. Fallback from immediate mode to normal mode is implicit as soon as all the immediate packets have been sent. Status indicating out of session is not strictly speaking a status, but rather a state where the state machine does not operate due to no session being active. Out of session state is entered after resetting the channel or node, as well as as a result of terminating the session either through the disconnection control function or a timeout that terminates the session.

When a session is established, the transmitter state machine enters the "TS" ("Sender Stopped") state due to the fact that before the receiving device has indicated that it is ready to receive data, the sender must assume that the device may be busy. Likewise, within any session, the first thing communicated in the session is a clear indication from the receiver sent to the transmitter to take the transmitter out of the "TS" state. The remaining states and causes that lead to movement between states will be understood on the basis of the diagram in fig. 13.

Fig. 14 shows the five basic receiver states: receiver active ("Receiver Active", "RA") when the receiver receives information; receiver waiting ("Receiver Waiting", "RW") when the receiver is able to receive data in terms of flow control but is not actually receiving data and therefore waits for data to become available; receiver stopped ("Receiver Stopped", "RS") indicates that the transmission of data has been stopped as a result of an indication from the transmitter state machine at the opposite end of the session that no more data needs to be sent this time; immediate mode receiver active ("Immediate Mode Receiver Activ", "IRA") entered from normal mode when there are immediate packets to be received; and Immediate Mode Receiver Waiting ("IRW"), which is equivalent to "RW", but occurs due to transport-level flow control when in immediate mode. Fallback from immediate mode or normal mode is implicit as soon as each immediate packet has been acknowledged. The status indicated as out of session is not strictly speaking a status, but rather a state where the state machine is not operating due to the fact that no session is in progress. Out of session state is after a reset of the IONET channel or node, as well as a result of the end of the session either through a disconnect control function or timeout that terminates the session.

Regarding the receiver state machine diagram shown in Fig. 14, the states and numbers and direction and the change conditions that set the states are identical to the diagram for the transmitter state machine in fig. 13, except that change from out of session state goes to the "RW" (receiver waiting) state rather than the "RS" (receiver stopped) state when establishing the session. Note the pairing of states shown in figures 13 and 14. Ordinarily, "TA" and "RA" are the pair that take care of active communication. If the transmitter has nothing more to transmit, it indicates passive and goes to "TW" state. The passive message from the sender places the receiver in "RS" state. The receiver will be moved from the "RS" state by the transmitter becoming active again, which is a change from "TW" back to "TA". If the receiver uses up all buffers to hold incoming data, it indicates a not ready state by going from "RA" to "RW". This moves the transmitter into the "TS" state. What moves the transmitter out of the "TS" state is a clear indication from the receiver, which occurs when the receiver is moved from "RW" back to "RA" when free buffers are again available. When active communication is taking place, both the transmitter and receiver are in their active states, "TA" and "RA". If the transmission has been suspended because the sender has nothing more to send, the sender is in "TW" and the receiver is in "RS", but if the transmission has been stopped because the receiver has no free space for more data, is the receiver in "RW" and the transmitter in "TS".

More specific details regarding the operation of the transmitter and receiver state machines are discussed below in connection with Figures 15, 16, 17 and 18.

The transmitter state machine handles all outgoing packets for a given device, provides the transmitter state byte "TXSB" for all packets it processes, generates sequence numbers for outgoing data packets, correlates acknowledgments with packets that have been sent, retransmits unacknowledged packets after a timeout, generating keep-alive packets at predetermined time intervals during periods when no outgoing data is available, and disconnecting if more than a larger second predetermined time period elapses without a state response from the corresponding receiver state machine.

Transmitter states for normal mode are shown in fig. 15. The states transmitter active ("Transmitter Active", "TA") are entered when there is outgoing data to send and when the sender is waiting for receipt of sent packets; transmitter waiting ("Transmitter Waiting", "TW"), entered when the last transmitted packet has been acknowledged and no more outgoing data is available; and transmitter stopped ("Transmitter Stopped", "TS"), entered when the receiver has stopped communication due to no buffers being available at the receiver. Dispatch of normal packages and of immediate packages are treated as independent activities. There is a semi-dependent transmission state machine for immediate packets, shown in fig. 16, which utilizes "ITA" and "ITS" transmitter states. After reset, as well as when no immediate packets are waiting or awaiting an acknowledgment, the transmitter state machine is in normal mode and uses "TA", "TW" and "TS".

When an immediate packet is to be sent while the sender state machine is in normal mode, the immediate mode enters an "ITA" state and sends the packet. Once the immediate state is entered, the sender state machine will remain in immediate mode until all pending immediate packets have been sent and acknowledged. At this point, the transmitter time machine returns to normal mode in the state that was active at the time the first immediate packet was presented.

Due to the simultaneous operation of the sender state machine and the receiver state machine at the two ends of each direction of each session, packets relating to normal priority can be received by a sender state machine while it is processing an immediate packet. These receptions are processed on the basis of the status of the normal mode transmitter, even if no other normal mode operation takes place before the immediate mode processing is finished.

The sender state machine expects positive acknowledgment for each immediate packet regardless of the value specified in the sender packet counter.

An array of integer values is maintained by the transmitter state machine to track message sequences and detect missing and/or duplicate packets. These include

n, which represents the present sequence number used for the transmission of packets with normal priority;

m, which represents the highest (normal priority) message sequence number that the corresponding receiver state machine has acknowledged for successful receipt;

p, representing the present sequence number used for transmission of immediate packets;

t, which represents the transmit packet counter used for this direction by the active session; and

x which represents a value in the range 0 to 15.

All order of magnitude relationships between these numbers are implemented so that the transition from 15 to 0 occurs when the order of magnitude increases. This is unambiguous because t must be less than 16.

The transmitter state machine indicates its state changes by operation code and sequence number in the transmitter state byte ("TXSB") of each transmitted packet. Permitted operations include

"DATAIn", which indicates that this packet contains byte streams or also administrative data and that this packet is a first or intermediate packet in a group of two or more packets sent without a positive acknowledgment;

"DATAFn", indicating that this packet contains bytestream and/or administrative data and that this packet is the last (or only) packet in a group, and that positive acknowledgment is required;

"IDLEn", indicating that no more data is currently (for now) available after data packet n-1;

"NOPx", used for keep-alive cases (sequence numbers are ignored);

"CONTROL COMAND", used for functions such as connecting, disconnecting, reporting device parameters, and so on (sequence number not used).

"COMMAND REPLY", used to send exit codes and response data in response to "CONTROL COMMAND" (sequence number not used).

The events that can lead to state changes in the transmitter state machine include

"READYn+1", indicating receipt of a packet to which receiver status byte contains acknowledgment type "READYn + 1", indicating that the receiver has successfully received all packets sent up to and including "DATAFn", and that the receiver has sufficient buffers available for a group of packets corresponding to the length of the active transmitter packet counter;

"BUSYn+1", indicating receipt of a packet to which receiver status byte contains acknowledgment type "BUSYn+1", indicating that the receiver has successfully received all packets sent up to and including "DATAFn", but that the receiver at the current time has no more buffers available (or an insufficient number of buffers to receive a group of packets equal to the length of the active transmitter packet counter);

"READYm+1", indicating receipt of a packet to which receiver state byte contains acknowledgment type "READYm + 1", indicating that the receiver state machine has successfully received all packets sent up to and including "DATAFm", has not successfully received packets sent with sequence number m+1, and that a new attempt

with package "m" (and subsequent) dispatch is required;

"Nothing sent, data available", indicating that one or more new outgoing packets have been presented for transmission at the time that no data packets have been sent since this "READYn+1", "READYm+1" or "Tl" event;

"DATAIn sent, more data available", indicating that one or more outgoing packets are additionally waiting for transmission at the time when at least one "DATAIn" packet has been sent since the last "READYn + 1", "READYm + 1", or "Tl" event;

"Tl", which shows that time interval related to retries and keep-alive-in packets, this time interval is reset every time a packet is sent to the session partner; and

"T2", which shows the expiration of the time interval related to the loss of communication or protocol destruction, this time period is reset every time a valid packet is received from the session partner.

Due to the various situations, including a previous attempt to send a packet to a device where its "RIM" receiver is prevented, there may be cases where a sender state machine is needed that sends a packet when its "RIM"- transmitter is busy. When this happens, the transmitter state machine will temporarily stop processing all events shown in its state change table, with the exception of the event relating to the exit of the "T2" interval. After a transmitter has become available, and is again made ready to send the pending transmission, any event that occurred during the period before the transmitter was busy will be processed. Processing of received "NOPx" packets (to reset "T2") is also deferred during periods when the transmitter is busy. Operation of the transmitter state machine in normal mode is characterized by

the table shown in fig. 15. For each box in the table, indicate names in capital letters

sending packets with the indicated function in the transmitter's status byte, names in lower case letters indicate internal operations within the transmitter state machine, and names beginning with a right arrow indicate the state entered upon termination of the activity in that box.

Other operational characteristics of the transmitter state machine are as follows. If more than one event occurs at the same time, the event shown in the leftmost column i

the table be processed first. Other events are only processed if they are still true after the initial event is processed. "Tl" time interval varies with transmitter state as shown, "T2" time interval is always a fixed value greater than "Tl".

Receipt of any receiver state message of "NOPx" (regardless of sequence number) causes the T2 interval to be reset, but is otherwise ignored by the receiver state machine. Sending a "CONTROL COMMAND" or a "CONTROL REPLY" can take place with "DATAFn" present. No further transmission takes place after a "CONTROL COMMAND" has been sent, until the corresponding "CONTROL REPLY" has been received. If the Tl time interval elapses while waiting for this "CONTROL REPLY", the "CONTROL COMMAND" will be retransmitted. No acknowledgment is expected or required for each "CONTROL REPLY". If the T2 time interval elapses without a "CONTROL REPLY" being received, the "CONTROL COMMAND " activity (and the session, if any) will be terminated. All packets received from the session partner with receiver state values other than those shown by the events defined in the state change table are ignored by the sender state machine without resetting the "T2" interval. This results in a timed session termination due to protocol destruction. There are also error states shown in the state change table that specify that the T2 time interval should not be reset. When establishing a session, or when resynchronizing, the transmitter state machine will enter the state TS with n:= m:= -1.

Operation of the transmitter state machine in immediate mode is characterized by

the table shown in fig. 16. For each box in the table, names in uppercase letters indicate dispatch of packets with the indicated function in the transmitter state group, names in lowercase letters indicate internal operations within the transmitter state machine, names starting with a right arrow indicate the state entered when the activity in the box ends, and the designation "Tx" refers to the normal modal state ("TA", "TW", or "TS") which is correct to enter upon termination of an immediate mode operation.

Other operational characteristics of the transmitter state machine in immediate mode are as follows. "Tl" time interval varies with transmitted status as shown, "T2" time interval is always a fixed value greater than "Tl". These "Tl" and "T2" time intervals are the same as those used by the normal mode transmitter state machine. Receipt of any receiver state message of "NOPx" (regardless of sequence number) causes the "T2" time interval to be reset, but is otherwise ignored by the transmit state machine. Sending a "CONTROL COMMAND" or a "CONTROL REPLY" can take place when "DATAFp" is available. No further transmission takes place after the "CONTROL COMMAND" has been sent, until the corresponding "CONTROL REPLY" is received. If the "Tl" time interval elapses while waiting for this "CONTROL REPLY", the "CONTROL COMMAND" will be retransmitted. No acknowledgment is expected, or required, for each "CONTROL REPLY". If the "T2" time interval expires without a "CONTROL REPLY" being received, the "CONTROL COMMAND " activity, session, if any, will be terminated. All packets received from the session partner with receiver-stauts values other than those described by the events defined in the state change table are ignored by the transmitter state machine without resetting the "T2" time interval. This results in a timed session termination due to protocol destruction. There are also error states shown on the state change table that specify that the "T2" time interval should not be reset. When establishing a session, or when resynchronizing, the value of p is initialized to zero. Upon entering immediate mode, the transmitter state machine will send a "DATAFp" packet and enter the "ITA" state. The value used for this "DATAFp" packet is unchanged from the previous output from immediate mode (or resynchronization).

The receiver state machine processes all incoming packets for a given device, provides the receiver state white group "RXSB" for incorporation into all outgoing packets from that device; generates sequence numbers for outgoing receipts; retransmits indications that free buffers are available if no new packets are received within a time interval; generates keep-alive packets at predetermined time intervals when no free buffers are available; and breaking the connection if more than a larger second predetermined time period has elapsed without a status response from the corresponding transmitter state machine being received.

Receiver states for normal mode are shown in fig. 17. The receiver states are receiver active ("Receiver Active", "RA") entered when one or more receiver buffers are available; receiver waiting ("Receiver Waiting", "RW"), entered when no receiver buffers are available; and receiver stopped ("Receiver Stopped", "RS"), entered when the transmitter has stopped communication because it has no outgoing data to send.

Receipt of normal packages and of immediate packages are treated as independent activities. There is a semi-dependent receiver state machine for immediate packets, which uses "IRA" and "IRW" receiver states. After reset, as well as when no immediate packets have been received and not yet acknowledged, are

receiver state machine in normal mode and uses "RA", "RW" and "RS".

When an immediate packet is received while the receiver state machine is in normal mode, immediate mode enters an "IRA" state and acknowledges the packet. Once the immediate state is entered, the receiver state machine will remain in immediate mode (status "IRA" and "IRW") until the received immediate packets have been acknowledged. At this point, the receiver time machine returns to normal mode in the state that was active at the time the first immediate packet was received.

Due to the simultaneous operation of the sender state machine and the receiver state machine at the two ends of each direction of each session, packets relating to normal priority can be received by a receiver state machine while it is processing an immediate packet. These receptions are processed based on the status of the normal mode receiver, even if no other normal mode operation takes place before the immediate mode processing is finished. This means that there must be at least one (generally exactly one) receiver buffer available when a receiver in normal mode enters the "RW" state.

The receiver state machine generates positive acknowledgment for each immediate packet regardless of the value specified in the receiver packet counter.

An array of integer values is maintained by the receiver state machine to track message sequences and detect missing and/or duplicate packets. These include

n, which represents the present sequence number used for receiving packets with normal priority;

m, which represents a sequence number, associated with a received packet of normal priority, which may be before n in sequence, but which is within the range of the active packet counter. When t=l is m=(n-l), when t is greater than 1 (n-1) is less than m is less than or equal to (n-1);

p, representing the present sequence number used for receiving immediate packets;

t, which represents the transmit packet counter used for this direction by the active session; and

x which represents a value in the range 0 to 15.

All order of magnitude relationships between these numbers are implemented so that the transition from 15 to 0 occurs when the order of magnitude increases. This is unambiguous because t must be less than 16.

The receiver state machine indicates its state changes using the acknowledgment code and sequence number in the receiver state byte of each packet it sends. Permitted receipts include

"READYn", indicating that the receiver has successfully received all packets sent up to and including "n-1", and that the receiver is in

capable of receiving the least number of packets allowed by the transmitter packet counter;

"BUSYn", indicating that the receiver has successfully received all packets sent up to and including "n-1", but currently has an insufficient number of buffers to receive a group of packets equal to the length of the active receiver packet counter ; and

"NOPx", used for keep-alive cases (sequence numbers are ignored); "DATAFn", indicating receipt of a packet where the transmitter status byte contains function type "DATAFn", indicating receipt of the next expected sequence value of the last (or only) packet in a group requiring positive acknowledgment;

"IDLEn" indicating receipt of a packet where the sender status byte contains function type "IDLEn", indicating that the sender currently has no more data to send;

"DATAFm", indicating receipt of a packet where the transmitter status byte contains function type "DATAFm", indicating that the transmitter state machine has not successfully received the last acknowledgment of a data packet and that a retry of that transmission (and subsequent transmissions) is in progress; (When t=l, m=(n-l), DATAFm is equal to DATAFn.);

"DATAIn", indicating receipt of a packet where the sender status byte contains function type "DATAIn", indicating receipt of the next expected sequence value of an initial or intermediate data packet in a group of data packets where acknowledgment will be generated after all packets have been received (which is indicated upon receipt of a packet of function type "DATAFn"); if the number of "DATAIn" events since the last "DATAFn" event exceeds the active transmit packet counter minus 1, reception of a "DATAIn" packet will be ignored.

"t receiver buffers available", indicating that at least "t" free receiver buffers have become available after a condition where less than "t" free receiver buffers have been free;

"T3", which shows that the time interval related to retries and keep-alive-in packets, this time interval is reset every time a packet is sent to the session partner; and

"T2", which shows the expiration of the time interval related to the loss of communication or protocol destruction, this time period is reset every time a valid packet is received from the session partner.

Operation of the receiver state machine in normal mode is characterized by

the table shown in fig. 17. For each box in the table, names in upper case indicate sending packets with the indicated function in the receiver's status byte, names in lower case indicate internal operations within the receiver state machine, and names beginning with a right arrow indicate the state entered upon termination of the activity in that box.

Other operational characteristics of the receiver state machine include: If more than one event is pending at the same time, the event shown in the leftmost column of the table will be finished processing first, before any consideration is given to those further to the right. Receiving a "CONTROL COMMAND" or a "CONTROL REPLY" causes the receiver state machine to reset the T3 time interval and forward the packet to the control facilities found in the device. The receiver state machine does nothing else, and will not acknowledge "CONTROL COMMAND" or every "CONTROL REPLY". The T3 time interval varies with the state of the receiver as shown, the T2 time interval is always a fixed time. Receipt of any transmitter status message "NOPx"

(regardless of sequence number) causes the T2 interval counter to be reset, but is otherwise ignored by the receiver state machine. All received packets from the session partner with sender status other than those covered by the defined events will be ignored by the receiver state machine without resetting T2. This will involve time-based recovery in case of protocol destruction. There are also error states shown in the state change table which specify that the T2 counter should not be reset. Upon reset or establishment of a session, the receiver state machine enters state "RW" with n: =0.

Operation of the receiver state machine in immediate mode is characterized by

the table shown in fig. 18. For each box in the table, names in uppercase letters indicate dispatch of packets with the indicated function in the receiver state group, names in lowercase letters indicate internal operations within the receiver state machine, names starting with a right arrow indicate the state entered when the activity in the box ends, and the designation "Rx" refers to the normal modal state ("RA", "RW", or "RS") which is correct to enter upon termination of an immediate mode operation.

Other operational characteristics of the receiver state machine in immediate mode are as follows. Receipt of a "CONTROL COMMAND" or a "CONTROL REPLY" packet causes the receiver state machine to reset the T2 time interval and forward the packet to the processing facilities that exist for control functions in the device. The receiver state machine does nothing else, and does not send acknowledgment on "CONTROL COMMAND" or every "CONTROL REPLY". "T3" time interval varies with receiver status as shown, "T2" time interval is always a fixed value. These "T3" and "T2" time intervals are the same as those used by the normal mode receiver state machine. Receipt of any transmitter status message of "NOPx"

(regardless of sequence number) causes the "T2" time interval to be reset, but is otherwise ignored by the transmission state machine. All received packets from the session partner with sender status other than those covered by the defined events will be ignored by the receiver state machine without resetting T2. This will involve time-based recovery in case of protocol destruction. There are also error states shown in the state change table which specify that the T2 counter should not be reset. Upon establishing a session or resynchronizing, the receiver state machine is set inactive with p initialized to 0. Upon entering immediate mode, the receiver state machine will enter "IRA" state with the value of "P" unchanged from the previous exit from immediate state (or from resynchronisation).

From the foregoing description of the IONET character channel in its various aspects, including the IONET protocol and the functionality of the state machine, the significance of the improvements available by the present invention should be apparent. This description should nevertheless not be interpreted as a limitation of the scope of the invention beyond the statutory scope of the following patent claims.

Claims (30)

1. A system for implementing a character I/O channel (140; 140a, 140b) for communicating byte stream data (266) and control administrative information (264) in a single IONET network level data packet message (240) from source to destination devices coupled to the channel (140; 140a, 140b) at a plurality of nodes (174), each source/destination device comprising an interface (182) coupled to an entity (176, 100; 176a, 100a, 100b) which is separate from the source/destination device, the entity (176, 100; 176a, 100a, 100b) being one of either an I/O device (176; 176A) directing I/O data transfers, or a computer (100; 100a, 100b ) comprising a storage (104), a processor (102) and program code for operating the computer (100; 100a, 100b), the character I/O channel (140; 140a, 140b) is arranged for use in connection with a local area network (LAN) comprising a communication medium (170; 170a, 170b) commonly connected to the plurality of nodes (174), LAN interface (178) at each node (174) to control e the access to the medium (170; 170a, 170b) and to communicate LAN packets between given selected source and destination nodes (174), each LAN data packet comprising a LAN data field and a LAN header field containing characters that control the interface means (178) to achieve node to node -communication in connection with a given LAN communication protocol, characterized in that the character I/O channel (140; 140a, 140b) comprises in combination: point of use ("POU") device (172) included in the source/destination device and connected to the LAN interface (178) by each node (174), the point of use means (172) is connected to each I/O device (176;176A) including a microcomputer (180) with storage and program code to operate the microcomputer (180), the program codes for the processor (102) and the microcomputer (180) defines a given I/O network communication protocol for communicating with the source/destination devices and their connected interfaces (182) and bodies (176, 100; 176a, 100a, 100b), the I/O network communication protocol being separate from The LAN communication protocol, point of use means (172) is arranged to insert characters into the data field of the LAN data packets to form I/O network network level data packet messages (240) having a field for I/O network header characters ( 260) and an administrative (264) and a byte stream data field (26 6), the I/O network header characters (260) include a function code (278) specifying one of a plurality of control functions, the administrative field characters include an administrative information code (264) for use in achieving specified control functions to be performed at one of the source/destination devices or interface (182), the byte stream data characters 266 originate from an entity (176, 100; 176a, 100a, 100b) at the source node (174), and the point of use means (172) at the destination node (174) is arranged to directly interpret the function code (278) and the administrative information code characters (264) a) to establish a session between the source and destination device to communicate I/O network data packet messages (240 ) between these without acceptance and interference from other I/O network data packet messages (240) throughout the duration of the session, and b) performing a corresponding control function on one of the destination devices or its interface (182) during the session, and c) simultaneously transmitting byte stream data characters (266) in unmodified form directly to the means (176,100; 176a, 100a, 100b) coupled to the interface (182) of the destination device. 2. System in accordance with claim 1, characterized by a management function which is a disconnection management function that ends an established session. 3. System in accordance with claim 1, characterized in that the I/O network header characters (260) comprise a length code (282,284) which specifies an arbitrary length for each of the administrative and byte stream data fields (264,266). 4. System in accordance with claim 1, characterized in that the I/O network header characters (260) comprise an immediate code (268), and the point of use device (270) at the destination device is arranged to immediately perform the control function specified by the function code (278) and the administrative information code (264) upon receipt of the I/O network message containing the immediate code (268). 5. System in accordance with claim 1, characterized in that the LAN interface (278) is arranged to be inserted into the source node identifying information (246,248,272) in each LAN data packet (240), and that the microcomputer (180) at a point-of-use means (172) is arranged to prevent responsive communication of I/O network messages to a source/destination device coupled at a node (174) having identification information (246,248) that does not match the node's identity information (246,248) by the source/destination devices with which the session was established. 6. System in accordance with claim 1, characterized in that the LAN interface (178) is arranged to insert a source node identification information (246,248,272) in each LAN data packet (240) and that the microcomputer (180) at a point-of-use entity (172) includes password information identifying the source (174) of each entity capable of initiating the session with the source/destination device at a point-of-use entity (172), and that the microcomputer (170) at a point-of-use entity (172) ) is arranged to prevent communication with I/O network messages except that source information (248) associated with received I/O network message during half a session corresponds to the source node identifying information (248) at the source/destination device which supplied password information to start the session. 7. System in accordance with claim 6, characterized in that the microcomputer (180) at the point of use means (172) further comprises a locking means to prevent password information from being changed by I/O network messages received from other source/destination devices. 8. System in accordance with claim 1, characterized in that an I/O network message specifying a command function is followed by communication of a response I/O network message containing function code (278) and an administrative information code (264) specifying whether the requested command function has been successfully executed. 9. System in accordance with claim 8, characterized in that each session is established by communication of a first I/O network message containing a function code (278) and an administrative information code (264) specifying a connection management function between two source/destination devices and by responsive communication of a spar I/O -net message containing a function code (278) and an administrative information code (264) specifying whether the session has been successfully established. 10. System in accordance with claim 9, characterized in that each session contains two half-sessions, the first I/O network message establishes one half-session and the response I/O network message establishes the second half-session. 11. System in accordance with claim 10, characterized in that the function code (278) and the administrative information code (264) of the response I/O network message are directly interpreted by one of the microcomputers (180) or the computer (100; 100a, 100b) at a source/destination device in the established session to prevent communication of further I/O network messages to other source/destination devices in the established section until further I/O network messages can be received in storage at the user point entity (172) at the other source/destination devices. 12. System in accordance with claim 10, characterized by that an I/O network data packet message contains multiple data packets (240) communicated in a half-session including I/O network header characters (260) arranged to specify sequential order information (268) of the multiple data packets (240), and each half-session response I/O network message includes I/O network header characters (260) specifying acknowledgment information (270) used to determine which of the data packets (240) were not successfully received. 13. System in accordance with claim 12, characterized in that all data packets (240) that were not successfully received are retransmitted in response to response I/O network message containing the acknowledgment information (270). 14. System in accordance with claim 12, characterized in that all data packets (240) which were not successfully received are retransmitted in response until the expiry of a given time period during which no response I/O network message had been received. 15. System in accordance with claim 8, characterized in that the response I/O network message contains characters (270, 278) in its I/O network header (260), which specify responses that include: successful completion of the management function, non-support of the management function by the destination device, rejection by the destination device of the control function due to of status at a receiver at the destination device, rejection of the control function due to that the destination device is not in session, rejection of the control function due to that the destination device is in session with another source/destination device, rejection of the control function due to that the configuration lock in connection with the destination device has been set, and rejection of the control function due to that there is an error in the control command character information in the control command I/O network message. 16. System in accordance with claim 1, characterized in that the control commands for the interface (182) comprise: a command to transmit the data packet message, a command to stop receiving data packet messages, and a command to communicate keep-alive messages to maintain the session in the absence of communicated data packet messages. 17. System in accordance with claim 8, characterized in that the control commands specify control functions including: reporting source/destination device parameters, which entails the generation of a control response I/O network message containing information relating to the type and given attributes of the device (176,100; 176a, 100a, 100b) connected to the source/destination device, report statistics, which entails the generation of a management response I/O network message containing statistics regarding medium communication, report interface parameters, which entails the generation of management response I/O network message concerning interface control and associated modal status at the source/destination device, set source/ destination device parameters, which means that the source/destination device can store new parameter information regarding other source/destination devices in the session, and set interface parameters, which causes the destination device to set new values for interface management and associated modal status. 18. System in accordance with claim 8, characterized in that the control functions include: "flush" buffers, which means that all previous information communicated in I/O network messages to stores at the receiver must be rejected, run extended diagnostics, which means that the source/destination device performs diagnostic functions and reports the results by these functions, and report status, which causes the source/destination device to generate a control response I/O network message that describes the status of an interface (182) at the device (176). 19. System in accordance with claim 8, characterized in that the response I/O network message includes information (268, 278) that specifies: status at source/destination interface input signal and an indication of common effect on/off and common ready/not ready status, selection of the input changes which results in communication control response I/O network messages containing status information, and specification of settings at the interface output control signals. 20. Method for character communication in a character I/O channel (140; 140a, 140b) for communicating byte stream data (266) and management administrative information (264) in individual I/O network data packet messages (240) at network level from source to destination device connected to the channel (140; 140a, 140b) at a plurality of nodes (174) when communicating LAN data packets between source and destination nodes in accordance with the LAN communication protocol, each source/destination device comprising an interface (182) which is connected to a device (176, 100, 176a, 100a, 100b) which is separate from the source/destination device, the entity (176,100; 176a, 100a, 100b) is one of either an I/O device (176,176A) conducting I/O data transfers or a computer (100; 100a, 100b) including a storage (104) and a processor (102) and program code for operating the computer (100; 100a, 100b), and the method is intended for use with a local area network (LAN) comprising a communication medium (170; 170a, 170b) typically connected to the majority of nodes (174), LAN interfaces (178) at each node (174) to control access to the medium (170; 170a, 170b) and communicate LAN packets between given selected source and destination nodes (174), each LAN data packet comprising a LAN data field and a LAN header characters field containing characters that control the interface (178) to achieve node communication in accordance with a given LAN communication protocol, characterized by comprising the following steps: including a point of use (POU) means (172) in the source/destination device and connecting the point of use means (172) to the LAN interface (178) at each node (174), including a microcomputer (180) comprising storage and program code for operating the microcomputers (180) in each point-of-use means (172), implementing an IONET communication protocol separately from the LAN communication protocol in the program code of each computer (100; 100a, 100b) and microcomputer (180 ) thus: forming IONET network level data packet messages (240) in accordance with the IONET communication protocol by inserting characters in the LAN data field of each LAN data packet communicated between the nodes (134); forming an IONET header field (160) and an administrative field (264) and a byte-stream data field (266) in each IONET data packet message (240) by inserting characters, the IONET header characters (260) including a feature code (278 ) that specifies one of a plurality of control functions, the administrative field characters comprise an administrative information code (264) for use in achieving the specified control function to be performed at one of the source/destination devices or its interface (182), byte stream data characters (266) have originating from a device (176,100; 176a, 100a, 100b) at the source node (174), and directly interpreting the function code (278) and administrative information code characters (264) at the destination node (174) in connection with IONET communication protocol, thereby a) establishing a session between source and destination devices to communicate IONET data packet messages (240) between them without acceptance of a interface from other IONET data packet messages (240) throughout the session, and b) perform a corresponding control function on one of the destination devices or its interface (182) during session, while c) simultaneously transmit byte stream data characters (266) in unmodified form directly to the device (176,100; 176a, 100a, 100b) connected to the interface (182) at the destination device. 21. Procedure in accordance with claim 20, characterized by further comprising: establishing a session to communicate byte stream data (266) in IONET messages (240), each session comprising two half-sessions, communicate first IONET message from a first source/destination device to the other source/destination device in a half-session, and communicating a response IONET message from the second source/destination device to the first source/destination device in the second half-session. 22. Procedure in accordance with claim 21, characterized by further comprising: communicating status information (268,270) regarding current and previous half-sessions with each response IONET message. 23. Procedure in accordance with claim 21, characterized by further comprising: i communicating an IONET message (240) to maintain the flow in an established session when byte stream data (268) is unavailable to communicate by the IONET data packet messages (240). 24. Procedure in accordance with claim 21, characterized by further comprising: interpreting the function code (270) and administrative information code (264) and performing a corresponding control function on one of the source/destination devices or interface (182) while the session is established, and communicate a response IONET message to indicate whether the control function was successfully executed, in 25. Procedure in accordance with claim 21, characterized by further comprising: including sequence information (268) in an I/O network data packet message (240) on a half-session that specifies the sequential order of multiple data packets (240), and acknowledging in a reply I/O network message in the second half-session those of the data packets (240) which have not been successfully received. 26. Procedure in accordance with claim 25, characterized by further including: retransmit those of the data packets (240) which have been acknowledged as not successfully received. 27. Procedure in accordance with claim 21, characterized by further including: retransmit I/O network data packet messages (240) that have previously been transmitted after the end of a given time period after which response I/O network message that acknowledges receipt of the messages that have not been received. 28. Procedure in accordance with claim 20, characterized by further including: establishing a session between those of the source/destination devices that are pre-selected to allow communication of I/O web messages (240) between them. 29. Procedure in accordance with claim 20, characterized by further including: divide the administrative and byte stream data fields (264,266) at each I/O net message into arbitrary lengths, each of which may contain no information, and specifying the length of each of the admin drive and byte stream data fields (264,266) by inserting characters into the I/O net header field (260) forming a length code (282,284). 30. Procedure in accordance with claim 20, characterized by further including: communicate multiple I/O network data messages (240), and limit the number of I/O network data packet messages (240) communicated in a group to a number that is at least one less than the number of I/O network data packet messages (240) which can be received in the warehouse at a destination device without obstructing a receiving body at a destination node (174).