Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
2001-09-17
2003-04-08
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C710S008000
Reexamination Certificate
active
06546430
ABSTRACT:
TECHNICAL FIELD
The described subject matter relates to network communications. More particularly, the subject matter pertains to arrangements and procedures to negotiate or select negotiable parameters used in the operation of networked components.
BACKGROUND
Multimedia information includes information that is interpretable by one or more of the five human senses such as sight and hearing. For example, video information is interpreted by the senses of sight and hearing. Audio information is interpreted by the sense of hearing.
There are many different types of systems in which multimedia signals or data are passed in a directed flow from source components (where the signals or data originate or enter the system), through transfer components (which may modify the signals or data), to sink components (where the signals or data terminate or exit the system). A multimedia distribution network is an example of such a system. In a multimedia content and services distribution network, audio and video data might originate from a gateway device (source component), pass through decompression components (transfer components), and be supplied to remote nodes (sink components) for viewing and listening.
FIG. 1
shows an example of a multimedia delivery and presentation system
100
of interconnected components. Functionally, the system retrieves a compressed stream of sampled data representing a video segment from a mass storage device
102
, decompresses the data, and displays it on a display device
110
. In addition to the two physical devices (mass storage device
102
and display device
110
), the system includes a source component
104
, a transfer component
106
, and a sink component
108
. Source component
104
is associated with a device driver
112
, in this case a hard disk driver to handle details of communication with the mass storage device
102
. The source component
104
retrieves data from the hard disk
102
at appropriate intervals and prepares or formats the data for subsequent handling by the transfer component
106
. The transfer component
106
is associated with decompression software
114
for decompressing data into a format suitable for handling by video display hardware. The sink component
108
receives the decompressed data and subsequently associates it with a video display driver
116
for transferring the decompressed data to a video display card and the associated display device
110
.
Traditionally, designers of multimedia delivery and presentation systems (e.g., the system of
FIG. 1
) specify individual components, along with various corresponding operational parameters (e.g., their individual propagation delays), and one or more direct connections between those components. The components, operational parameters, and direct connections are typically specified one at a time, in an arbitrary sequence.
Multimedia data exists in a number of different data formats and various communication protocols are available to transfer such data between networked devices. One issue that needs to be resolved, either by the components themselves or by the component assembly system on behalf of the components, is the format of the data as it is passed from each component to the next. It may be that each component supports a number of different operational parameter combinations such as data formats, communication speeds and/or protocols. However, it will often be the case that the different components do not support the same sets of operational parameters. (Hereinafter “operational parameters” in general are often to referred to as “format parameters”).
One way to negotiate format parameters is to allow each connected group of components to negotiate among themselves as they are being connected. In the example of
FIG. 1
, source component
104
and transfer component
106
would initially negotiate to select an optimum set of format parameters supported by both of the components. Once this connection was completed, the transfer component
106
and sink component
108
would negotiate to select another set of format parameters supported by both of these components. In practice, each component would implement a negotiation interface which would be used to actively arbitrate with other components in determining a common communication format.
While this type of negotiation scheme might work in many situations, it does not always result in the optimum overall parameter selection. In this scheme, parameter decisions are made locally as individual components are connected. However, the most efficient parameter selection between two components may not be the most efficient selection when the entire path is considered.
For instance, it might be in the example of
FIG. 1
that source component
104
and transfer component
106
both support a very efficient data format as well as a slightly less efficient data format, while sink component
108
supports only the less efficient format. Based on the scheme described above, the most efficient format would be chosen for the interconnection between source component
104
and transfer component
106
. However, this format would not be available for the interconnection between transfer component
106
and sink component
108
, so a format conversion would be required to convert the data to the less efficient format for subsequent transfer to sink component
108
. In this situation, it would have been more efficient to select the less efficient format for all interconnections, thus avoiding the processing penalty of the format conversion.
In practice, the problem of choosing appropriate or optimum format parameters can become far more complex than indicated by the example of FIG.
1
. For instance, each component may have multiple input ports and multiple output ports, each of which might be connected to a different component. In addition, a negotiated parameter selection on one port of a component might impose restrictions on the format parameters available at other ports of the same component. Furthermore, there may be a hierarchy of parameter information, such that making one decision in a negotiation not only affects the choices that can be made for other parameters, but even determines which other parameters are relevant to the negotiation.
Even the task of designing negotiation interfaces is problematic. For instance, it is difficult to define interfaces that effectively support radically different classes of communication formats, since each class may require a substantially different form of negotiation. Furthermore, implementation of a negotiation interface requires a high degree of intelligence in each component, thus impeding the automation of the negotiation process. This requirement for component-level intelligence places a significant burden on the implementer of each component. One mechanism that can be employed to ease this burden is the creation of generic ports, which are component ports that contain all of the basic logic for data exchange and parameter negotiation, yet are not specific to any type of component. These generic ports can be instantiated by the component designer and modified as necessary to support the component's negotiation needs. However, since the negotiation interface that each port presents is so heavily dependent upon the classes of communication formats that are supported by the port's component, definition and implementation of generic ports is a difficult problem, and one that has no obvious solution.
It is apparent that the previously proposed methods of negotiating or selecting communication parameters for use among groups of interconnected components have a number of problems. The following subject matter addresses these problems and allows parameters to be selected to provide the optimum overall performance.
SUMMARY
In a distributed network of interconnected multimedia source, transfer, and sink components, the described arrangements and procedures defer parameter selection until all relevant information is available. Parameter decisions are made only after all allowable valu
Douceur John R.
Glass Adam
Gray, III Donald M.
Lee & Hayes PLLC
Microsoft Corporation
LandOfFree
Negotiating optimum parameters in a system of interconnected... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Negotiating optimum parameters in a system of interconnected..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Negotiating optimum parameters in a system of interconnected... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3013818