Browse Prior Art Database

Generic Communication in a Multi-Component Computer System Model

IP.com Disclosure Number: IPCOM000122976D
Original Publication Date: 1998-Jan-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 4 page(s) / 161K

Publishing Venue

IBM

Related People

Donnelly, CM: AUTHOR [+2]

Abstract

When building a computer system simulation model out of independent component models, a generic communication structure may be utilized which not only simplifies the transmission of typical "messages" between component models (e.g., the transfer of X bytes starting at address A), but also has the flexibility to transmit complicated (i.e., metalevel) messages. A set of fields comprising such a communication structure is disclosed.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 35% of the total text.

Generic Communication in a Multi-Component Computer System Model

      When building a computer system simulation model out of
independent component models, a generic communication structure may
be utilized which not only simplifies the transmission of typical
"messages" between component models (e.g., the transfer of X bytes
starting at address A), but also has the flexibility to transmit
complicated (i.e., metalevel) messages.  A set of fields comprising
such a communication structure is disclosed.

      If a computer system simulation model is built from truly
independent component models, the component models must conform to a
predefined specification that allows the models to communicate via
some sort of generic communication medium.  This disclosure does not
cover the difficulties of actually connecting such components into a
coherent computer system model, but rather focuses on the structure
of the "messages" that are passed back and forth to accomplish the
actual simulation of system activity.  In particular, it focuses on
the individual pieces of information that comprise the messages,
ignoring the method for transmitting that information (e.g., discrete
variables vs. complex conglomerations of data, literal
message-passing vs. entry-point subroutines with identical arguments,
etc.). Throughout  this disclosure, the term "message" will be used
to refer to the medium  of communication between two component
models.  Again, this is not intended to imply that message-passing is
the preferred method of communication, nor that the individual pieces
of information comprising a  message must be compacted into a single
unit of transfer.  The types of  information found in the generic
"message" structure may be loosely divided into four areas: message
routing, message type, data transfer,  and metalevel communication.

      Up to five pieces of routing information may be pertinent and
should, therefore, be either directly or indirectly specified.
First, the original source of the message should be identified.  This
identification includes: the specific component type (e.g., ABC Host
Bridge), which (typically) corresponds to one of the individual
component models; the specific instance of the component type (e.g.,
Bridge #2) and  the specific "port" used to send the message towards
its destination (e.g., Port #2, which might be the "downstream" side
of the bridge).  This three-tuple allows for easy "return addressing"
of any replies to the message.  The final destination should be
similarly specified, with the "port" indicating the port of the
destination component that will be receiving the message (if known in
advance). This  allows components along the path between the source
and the destination  to successfully route the message.  The
intermediate source and intermediate destination should also be
specified, indicating the two components that are currently involved
in passing the message.  The path  from so...