Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-11-04
2002-04-09
Harrell, Robert B. (Department: 2152)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S231000, C709S227000, C709S229000
Reexamination Certificate
active
06370592
ABSTRACT:
BACKGROUND
The present invention concerns networking of peripherals of computing systems and pertains particularly to a network interface device which allows peripherals to utilize network transport services.
Networked systems allow a user working on a computer system to utilize various peripheral equipment distributed at various locations either close to or at a distance from the use. For example the peripheral equipment can include a printer or a scanner or some other type of peripheral equipment which is connected through one or more networks to the computer system.
Various transport protocols can be used by the computing system to communicate with the peripheral equipment. For example, standard protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), Internetwork Packet Exchange (IPX), or Sequenced Packet Exchange (SPX) may be used. Each of these protocols can be referred to as a network transport service
To allow peripheral equipment to interact with various network connection services, an interface device is often attached to the peripheral equipment. The interface device provides the peripheral equipment with the ability to communicate using one or more network connection services. Such an interface device is often referred to herein as an input/output (I/O) device or an interface card.
Generally, each network connection service supported by each interface device has required joint definition and implementation in both the interface device and the peripheral equipment. Therefore, every time a new network connection service is added, support for the network connection service must be added into both the interface device and the peripheral equipment. This can require a significant amount of engineering resources.
The Xport Interface Protocol, Version 1 (XIPV1), developed by Hewlett-Packard Company, having a business address of 3000 Hanover Street, Palo Alto, Calif. 94304, has supplied a limited solution to the above described problem. Specifically, XIPV1 supports datagram transport service using the UDP and IPX protocols. However, there is no support for reliable stream transport services, such as the TCP protocol and the SPX protocol. Thus in XIPV1, network connection services require joint definition and implementation in both the interface device and the peripheral equipment.
Another weakness of XIPV1 is that only a single communication channel between the peripheral equipment and the interface device is used. As a result, when the peripheral equipment uses multiple datagram communication endpoints, there is no way to control data flow between the endpoints. Thus communication on one endpoint can monopolize the single channel and “starve” other endpoints.
SUMMARY OF THE INVENTION
In accordance with the preferred embodiment of the present invention, an input/output device is connected to peripheral equipment. For example, the peripheral equipment is a printer or a scanner, and the input/output device is an interface card. The input/output device includes a plurality of network transport modules. Each network transport module implements a different network protocol. The input/output device includes a communication mechanism for communication with the peripheral equipment.
The input/output device also includes a gateway module, which interacts with each of the network transport modules and with the communication mechanism. For each endpoint within the application programming interface (API) module within the peripheral equipment, a corresponding endpoint is implemented within the gateway module. A control channel between the gateway module and the API module is used to transport control messages between the gateway module and the API module. For a network transport module which requires data stream communication, control messages are exchanged over the control channel and data stream communication is established via a separate communication channel between the gateway module and the API module.
In the preferred embodiment, the separate communication channel is initiated by the API module sending a connection request message to the gateway module. The gateway module first responds by returning a connection acknowledgment message to the API module and forwarding the connection request to the local transport service which initiates a connection to a remote host. The gateway module sends a confirmation indication message to the API module upon the gateway module establishing a connection with the remote host.
Also, the separate communication channel can be initiated by the gateway module sending a connection indication message to the API module upon the gateway module receiving a connect request from a remote host. The API module responds by sending an accept request message to the gateway module. The gateway module responds by sending an accept acknowledgment message to the API module.
For example, the separate communication channel is released by the API module sending an end of peripheral data message to the gateway module via the communication channel. The API module also sends an orderly release request to the gateway module via the control channel. The gateway module responds by sending an orderly release acknowledgment message to the API module via the control channel. When the remote host sends an end of connection indication, the gateway module sends an end of host data message to the API module via the communication channel. The gateway module sends an orderly release indication message to the API module via the control channel. The API module sends an end of host data acknowledgment message to the gateway module via the communication channel.
Alternatively, the separate communication channel is released by the gateway module sending an end of host data message to the API module via the communication channel. The gateway module sends an orderly release indication message to the API module via the control channel. When the remote host requests the API module to release the connection, the API module sends an end of peripheral data message to the gateway module via the communication channel after the application requests the API module to release the connections. The API module sends an orderly release request to the gateway module via the control channel. The API module sends an end of host data acknowledgment message to the gateway module via the communication channel. The gateway module responds by sending an orderly release acknowledgment message to the API module via the control channel.
In the preferred embodiment, when the network transport module becomes disabled, the separate communication channel is released by the gateway module sending an end of host data message to the API module via the communication channel. The gateway module sends a new state indication message to the API module via the control channel. The API module sends an end of host data acknowledgment message to the gateway module via the communication channel. The API module sends a new state response message to the gateway module via the communication channel. The gateway module signals that the transport module is enabled by sending a new state indication message to the API module via the control channel. The API module responds by sending a new state response message to the gateway module via the communication channel.
In the preferred embodiment, a local protocol address is bound to a previously opened endpoint by the API module sending a bind request message to the gateway module. The bind request message includes a bind sequence number. The gateway module sends a bind acknowledge message to the API module.
Also in the preferred embodiment, the API module obtains system parameters of the input/output device by sending a system information request message to the gateway module. The gateway module sends a system information acknowledgment message to the API module. The system information acknowledgment message includes information on the parameters of the input/output device.
The present invention allows peripheral equipment to add network services witho
Harrell Robert B.
Hewlett--Packard Company
Vaughn, Jr. William C.
LandOfFree
Network interface device which allows peripherals to utilize... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Network interface device which allows peripherals to utilize..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Network interface device which allows peripherals to utilize... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2913282