Electrical computers and digital processing systems: multicomput – Master/slave computer controlling – Master/slave mode selecting
Reexamination Certificate
1999-11-02
2003-09-09
Coulter, Kenneth R. (Department: 2142)
Electrical computers and digital processing systems: multicomput
Master/slave computer controlling
Master/slave mode selecting
C709S221000, C709S242000
Reexamination Certificate
active
06618750
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to communication path determination techniques. More particularly, this invention relates to methods for determining communication paths between devices where multiple coupling, mechanisms are implicated.
2. The Prior Art
The IEEE 1394 multimedia bus standard is to be the “convergence bus” bringing together the worlds of the PC and digital consumer electronics. It is readily becoming the digital interface of choice for consumer digital audio/video applications, providing a simple, low-cost and seamless plug-and-play interconnect for clusters of digital A/V devices, and it is being adopted for PCs and peripherals.
The original specification for 1394, called IEEE 1394-1995, supported data transmission speeds of 100 to 400 Mbits/second. Most consumer electronic devices available on the market have supported either 100 or 100/200 Mbits/second; meaning that plenty of headroom remains in the 1394 specification. However, as more devices are added to a system, and improvements in the quality of the A/V data (i.e., more pixels and more bits per pixel) emerge, a need for greater bandwidth and connectivity flexibility has been indicated.
The 1394a specification (pending approval) offers efficiency improvements, including support for very low power, arbitration acceleration, fast reset and suspend/resume features. However, not all devices meet the 1394 specification and not all devices communicate by way of the same protocols.
In distributed driver architectures, multiple communication paths may sometimes be available for controlling a remote device. For example, a 1394 and RS-232 serial connection may exist between two nodes implementing a distributed driver architecture. In order to determine the best connection to use, an application has to be able to determine the communication path of each connection.
Old methods of distributed driver architectures (e.g., the Home Audio/Video interoperability, or HAVi, architecture) do not provide any means of ascertaining the communication path used to access a remote device. Only an ID is given for the end device. In the case where two communication paths are available, some implementations may provide two distinct IDs but no means for determining the communication path used for each ID.
BRIEF DESCRIPTION OF THE INVENTION
This invention provides a method for determining the communication paths used to access remote devices. In the case of two nodes connected by two paths and an ID for each path for a remote device, this invention provides a means of ascertaining the communication path associated with each ID.
In one implementation of this invention, each driver in the distributed system provides a device name stack service which returns a string containing an ordered list of the names of the drivers in the driver stack. For most drivers in a driver stack, this service calls the device name stack service for the next driver down the stack and then adds the name of the current driver. This recursive procedure will produce the ordered list of the names of the drivers in the driver stack where the highest layer driver name is first and the lowest layer driver name is last.
In the case of distributed drivers, the device name stack service starts by performing activities within the capabilites of regular local drivers. This first activity produces a list of names of drivers down to the lowest driver used for transmitting messages to the remote node. The resulting string only contains local driver names. It does not provide any information about the remote node. Thus, the second activity of the device name stack service sends a message to the remote node requesting its device name stack service. The receiving driver will have two driver stacks below it, one for the messaging stack and the other for the target device driver stack. The remote driver's device name stack service then calls the device name stack service for its messaging stack and reverses the order of the list of driver names; thus the lowest layer driver name is first and the highest layer, that of the remote driver, is last. Then, the remote driver's device name stack service calls the device name stack service for its target device driver stack and appends the result to the reversed messaging device name stack and returns it to the local node. The local device name stack service appends the remote device name stack to the local device name stack which results in an ordered list of device driver names participating in the communication path between the local node's application and the remote target device.
This same method may be used to produce a list of device classes, device unique IDs, or any other information desired of the communication path. That is, instead of merely indentifying the drivers, path specific information may be obtained instead. For instance, instead of ascertaining that the path in question includes a 1394 link, perhaps throughput information would be provided.
This method may also be used in a bridged system where the remote target device resides on a different bus from the local node with an intermediate bridge node. In this manner, a path including the bridge may be ascertained as may be useful in certain applications.
The information provided by the device name stack may be used by a controlling application to determine the best communication path to use when multiple paths are available for the same remote target device. Thus, in the case where both 1394 and RS-232 communcation paths are available, the application can determine which device driver ID corresponds to the 1394 path and use that one due to it's higher performance capabilities.
Therefore it is an object of the present invention to detemine communication paths is a system of nodes.
It is another object of the present invention to differentiate one of many communication paths amongst a plurality of nodes in a system.
It is yet another object of the present invention to provide the communication paths determined in an ordered string including relevant driver information therein.
Viewed from a first vantage point a method for building a communication path representation is disclosed, comprising in combinaiton, getting driver information for each driver in the path; ordering said driver information sequentially in a list; and presenting said list upon request to requesting applicaitons.
Viewed from a second vantage point a communication path determination system is disclosed, comprising in combination, a plurality of nodes; one or more communication paths coupling said plurality of nodes to each other; and means for defining said communication paths in ordered lists.
Viewed from a third vantage point in a memory space, a method for determining a communication path is disclosed, comprising in combination, starting a local name stack service; gathering information about all local drivers on one or more communication paths; adding said local driver information to one or more ordered lists correlated to each communication path; starting a remote node name stack service; gathering information about all remote node drivers; ordering said remote node driver information in a list; and adding, said remote node ordered list to said local node ordered list.
REFERENCES:
patent: 4156798 (1979-05-01), Doelz
patent: 4194113 (1980-03-01), Fulks et al.
patent: 5014262 (1991-05-01), Harshavardhar
patent: 5274631 (1993-12-01), Bhardwaj
patent: 5343461 (1994-08-01), Barton et al.
patent: 5394556 (1995-02-01), Oprescu
patent: 5406643 (1995-04-01), Burke et al.
patent: 5452330 (1995-09-01), Goldstein
patent: 5490253 (1996-02-01), Laha et al.
patent: 5495481 (1996-02-01), Duckwall
patent: 5539390 (1996-07-01), Nagano et al.
patent: 5541670 (1996-07-01), Hanai
patent: 5568641 (1996-10-01), Nelson
patent: 5583922 (1996-12-01), Davis et al.
patent: 5621659 (1997-04-01), Matsumoto et al.
patent: 5630173 (1997-05-01), Oprescu
patent: 5640595 (1997-06-01), Baugher et al.
patent: 5642515 (1997-06-01), Jones et al.
patent: 5684715 (1997-1
Apple Computer Inc.
Coulter Kenneth R.
Nguyen Chau
Sierra Patent Group Ltd.
LandOfFree
Method and apparatus for determining communication paths does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for determining communication paths, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for determining communication paths will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3004726