Command-based communications between an initiator and a target

Electrical computers and digital data processing systems: input/ – Input/output data processing – Input/output command process

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C710S020000, C710S033000, C710S052000

Reexamination Certificate

active

06477587

ABSTRACT:

BACKGROUND OF THE INVENTION
The present invention relates to a communication method and apparatus for connecting devices such as a host computer, printer, and the like.
In recent years, an IEEE1394 interface is prevalently used in connections of a computer and peripheral device or of different peripheral devices. The IEEE1394 interface can assure fast, two-way communications compared to handshaking such as a Centronics interface or the like. Also, since the IEEE1394 interface is a memory bus model interface, devices connected via the IEEE1394 interface can read data at a designated address or can write data at a designated address with respect to a partner device.
The IEEE1394 standard defines the protocols of the physical and link layers in only broad terms, and does not define detailed protocols in units of devices. For this reason, the protocol of the transport layer such as SBP (Serial Bus Protocol)-2, which uses IEEE1394 as physical and link layers, has been proposed. The transport layer provides a data transfer function to an application, and applications that use this layer can exchange data with each other.
The SBP-2 protocol exploits the feature of the IEEE1394 standard as a memory bus model. When the SBP-2 protocol is used, the target side can receive data and send out at its convenience. Protocols other than SBP-2 can transfer asynchronously generated data, can realize multi-channels, and so on, but cannot exploit the feature of IEEE1394 as a memory bus model. More specifically, when a certain protocol other than SBP-2 is applied to communications between a host and printer, data from the host cannot be received at the convenience of the printer side, and the host must transfer data while monitoring the printer state.
In SBP-2, upon transferring data, the transmitting side initially performs login operation to establish a channel with a communication partner. In this case, the login side is called an initiator, and the partner side connected to the initiator is called a target. Data is transferred by reading/writing data from/in a buffer of the initiator in accordance with an instruction from the initiator. In this method, the initiator generates an ORB (Operation Request Block) including the address and size of the buffer where data is stored, and the like, and informs the target of the address in the ORB. The target reads out data from the initiator or writes data on the basis of the buffer address or size in the ORB according to its own convenience. After such process, the target generates a status block, and informs the initiator of completion status.
When a communication is made using the SBP-2 protocol built on the IEEE1394 interface, especially, when a data source such as a host computer or the like is used as an initiator and data is transferred to a peripheral device such as a printer device or the like which serves as a target, the following four problems are posed.
(Problem 1) A complicated sequence is required due to full-duplex communications.
In SBP-2, data transfer is basically managed by the initiator, and the target cannot asynchronously transfer data to the initiator. More specifically, in ordered model of SBP-2, when the target wants to transfer data to the initiator, it issues unsolicited status to the initiator and sends a data read request. In response to this request, the initiator generates an ORB, and adds the generated ORB to the end of a list of outstanding ORBs (including a data transfer request from the initiator to the target, and the like). Since those ORBs are processed in turn from the head of the list, the ORB corresponding to read request that is issued by the target to the initiator is processed not at its issuance timing but only after the ORB process of the initiator progresses, and the ORB generated in response to the data read request from the target is processed. Then, the target transfers data to the initiator. Hence, two-way asynchronous data transfer cannot be done. For this reason, when data to be transferred from the target to the initiator is generated asynchronously, data to be immediately sent to the initiator is not guaranteed to be sent in finite period. For example, when the target is a printer and an error has occurred in that printer, the initiator cannot be informed of the error because the execution of target is blocked by the error.
For this reason, in order to promptly transfer data asynchronously generated in the printer to the host, a login procedure must be performed using the printer as the initiator, and data transfer having the host computer as the target must be done.
In such situation in which the host computer and printer log in each other and serve as both the initiator and target, processes as the initiator and target must be equipped in both the host computer and printer. Also, the login operation must be performed from the printer.
A peripheral device such as a printer which processes images consumes many memory resources and processor resources to attain image processing. For this reason, in order to simplify the device arrangement and to reduce cost or to attain quick processing, resources used for purposes other than image processing must be eliminated as much as possible. However, when many processes must run, as described above, more resources are consumed accordingly contrary to these objects, i.e., a cost reduction and efficient processing.
For example, in case of the host computer and printer, data that flow in the respective directions can be associated with each other, e.g., print data and its processing status. However, when channels are set by independent logins in the respective directions, print data and its response must retain correspondence to each other, and another processing sequence must be added for this purpose.
As described above, direct application of IEEE1394 and SBP-2 to communications between the host computer and printer is improper, and makes it hard to reduce resources required in the respective devices and to improve efficiency.
(Problem 2) Multi-channels cannot be realized.
Recently, a hybrid machine that combines various functions has prevailed as a peripheral device. For example, a digital hybrid machine which can be used as a standalone scanner, printer, or facsimile by, e.g., a host computer, is available. Upon using such device, a plurality of functions can be simultaneously used if communications are made via a plurality of independent channels in units of independent functions.
However, since SBP-2 cannot provide multi-channels, it is hard to simultaneously use such independent functions.
(Problem 3) SBP-2 cannot cope with bus reset.
In the IEEE1394 interface, upon a status change that changes the network configuration, such as new attachment or disattachment of a device to an IEEE1394 serial bus, or power ON or OFF of the attached device, bus reset is generated. The bus reset is generated when a node that has detected the aforementioned status change on the bus transmits a bus reset signal onto the bus. The generated bus reset signal is transmitted from one node to another, and when all nodes on the network have received the bus reset signal, a series of operations for bus reset are executed in each node.
In this way, bus reset is generated asynchronously with the processes in the nodes on the network. On the other hand, even in a given node which is not related to the node that has caused the bus reset in terms of an application, once the bus reset has been generated, that node must execute the bus reset processing. In the process of bus reset, nodes which are communicating with each other according to SBP-2 are disattached, and even when these nodes are re-attached, it is not guaranteed if the process can be continued from the state immediately before bus reset.
SUMMARY OF THE INVENTION
The present invention has been made in consideration of the aforementioned prior art, and has as its object to provide a communication control method and apparatus, which allow full-duplex communications (asynchronous two-way communications) by a single login process and

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Command-based communications between an initiator and a target does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Command-based communications between an initiator and a target, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Command-based communications between an initiator and a target will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2944890

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.