Method and system for using a universal serial bus (USB) as a peer-to-peer network

In one embodiment, the system includes a host processor and a plurality of devices connected to the host processor via a USB interface. Each of the devices includes at least a processor and USB controller hardware. The host processor includes message handling logic and each of the devices also include message handling logic that is configured to cooperate with the device to prepend a communication protocol header to a message that one of the devices desires to send to the host or to another of the devices. The host processor and each of the devices are peers with respect to each other. A router located in the host processor analyzes the communication protocol header to determine whether the message is destined for the host processor or for one of the other devices.

TECHNICAL FIELD

The present invention relates generally to computer networking, and, more particularly, to a method and system for using a universal serial bus as a peer-to-peer network.

BACKGROUND OF THE INVENTION

A peer-to-peer network is defined as a plurality of computers connected by an electronic network in such a way that each computer can both initiate message transmissions to any other computer on the network, and receive message transmissions from any other computer on the network. A local area network (LAN) is an example of a peer-to-peer network.

The universal serial bus (USB) is a communication bus architecture associated with computing devices that generally allows host-to-device communication through the exchange of packets, or messages. The USB messages typically include header information and data. For example, in the context of a personal computer, the computer processor could be considered the host, and the mouse, keyboard, printer, joystick, disk drives, etc. could be considered the devices that communicate with the host. The conventional USB protocol specifies that all communication messages be transferred between the USB host and the devices attached to the host. The USB architecture is economical to employ due to the availability of competitively priced microprocessors that include an integrated USB device interface.

The conventional USB protocol is also useful for communication in which large bandwidth and the ability to “hotswap” processor modules is important. The term “hotswap” refers to the situation in which a USB device is removed from an operating computer system and replaced with another processor without removing power from the system.

Unfortunately, this conventional protocol, by requiring that all communication between devices connected to the USB occur between the host and each device, prevents device-to-device, also referred to as “peer-to-peer” communication.

Therefore, a need exists for a high bandwidth communication protocol and bus that allows the removal and replacement of processor modules without removing power from the system and that allows peer-to-peer communication between devices connected to a communication bus.

SUMMARY OF THE INVENTION

The invention provides a method and system for peer-to-peer communication between devices connected to a USB.

The invention may be conceptualized as a method for using a USB as a peer-to-peer network, the method comprising the steps of: connecting a host processor to a USB, the host processor including a router, and connecting a plurality of devices to the USB, each of the devices being peers with respect to each other and with respect to the host processor. The method also includes the steps of forming a message in one of the plurality of devices or the host processor, prepending a header to the message, and transporting the message from one of the devices directly to any other of the devices or the host processor through the router and over the USB.

In architecture, the invention is a system for using a USB as a peer-to-peer network, comprising: a host processor including a message handler. The host processor is configured to prepend a header to a message and the host message handler is configured to recognize the header. The system also includes a plurality of devices associated with the host processor, each of the devices including a device message handler. Each of the plurality of devices is configured to prepend the header to the message. The device message handler is also configured to recognize the header. The system also includes a router associated with the host processor, the router configured to route the message over a USB directly between the host processor and any of a plurality of the devices associated with the host processor.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Although the preferred embodiment of the method and system for using the USB as a peer-to-peer network will be described in the context of a number of microprocessor driven devices interacting with each other using a USB for the purpose of controlling a server computer system, the invention is applicable in any situation in which a number of devices communicate over a USB.

The method and system for using the USB as a peer-to-peer network can be implemented in hardware, software, firmware, or a combination thereof. In the preferred embodiment(s), the invention is implemented in a combination of hardware and software or firmware. The hardware or firmware can be stored in a memory and be executed by a suitable instruction execution system. If implemented in hardware, as in an alternative embodiment, the invention can be implemented with any or a combination of the following technologies, which are all well known in the art: a discrete logic circuit(s) having logic gates for implementing logic functions upon data signals, an application specific integrated circuit (ASIC) having appropriate combinational logic gates, a programmable gate array(s) (PGA), a field programmable gate array (FPGA), etc.

Turning now to the drawings,FIG. 1is a block diagram illustrating a server system11, which will be used to illustrate the concept of the invention. It should be noted that although shown as a server system11, the method and system for using the USB as a peer-to-peer network is applicable to any system in which a number of processor devices, each having a USB interface, communicate over the USB in a peer-to-peer arrangement. Server system11can be divided into a number of cabinets. For example, for illustration purposes server11is divided into nodes, sometimes referred to as cabinets27and28. Cabinet27includes memory element12and processor14. Cabinet28includes memory element36and processor37. Each cabinet27and28also includes a utilities subsystem50and30, respectively, which controls and monitors memory elements12and36and processors14and37, respectively.

Utilities subsystem50includes a number of processor devices connected to and in communication via USB20and is illustrated herein as including cabinet level utilities (CLU) device60, power monitor3(PM3) device70, system abstraction layer interface network controller (SINC) device100and service processor200. Multiple utilities subsystems50and30are illustrated because in a typical application, each utilities subsystem50and30includes many iterations of the CLU device, PM3device and the SINC device, and also includes additional processor and control devices. However, for simplicity, only two iterations of the utilities subsystem, each having one iteration of the CLU device, the PM3device, the SINC device and, in the case of utilities subsystem50, the service processor200are shown. Note, however, that only one service processor200(located in utilities subsystem50) is associated with server11. In accordance with an aspect of the invention, service processor200acts as a host processor. Because the USB protocol allows only one host, no matter the number of utilities processors and associated devices, there is only one service processor200. Importantly, and in accordance with an aspect of the invention, each of the devices within each utilities subsystem50and30communicates via USB20.

SINC device100communicates with and controls memory12and processor14via connection21. CLU device60communicates with and controls backplane element16via connection22and PM3device70communicates with and controls power supply and fan module18via connection24. Similarly, SINC device31communicates with and controls memory36and processor37via connection41. CLU device32communicates with and controls backplane element38via connection42and PM3device34communicates with and controls power supply and fan module39via connection44.

FIG. 2is a block diagram illustrating the utilities subsystem50of FIG.1. Utilities subsystem50includes service processor200, which communicates via USB20with SINC device100, CLU device60and PM3device70. Service processor200comprises both hardware and software elements operating in cooperation to control the operation of utilities subsystem50. Service processor200communicates via USB20using USB host controller226and USB host driver224. USB host controller226is a hardware element (a USB controller chip) and USB host driver224is a corresponding software driver used to control the USB communication.

Service processor200also includes operating system221, which is the software element that controls the operation of service processor200. Service processor200also includes USB router218. USB router218communicates with operating system221via device drivers220, which will be explained in further detail below, and which provide the logical connection between the service processor200and each of the devices60,70and100within utilities subsystem50.

Service processor200also includes a number of software modules that provide various functionality to server system11. For example, service processor200includes scan support module208and firmware update module211, as well as other modules that are part of the overall design of the server system11and which rely on communication with other USB-connected microprocessors. Essentially, service processor200provides a variety of control functions within utilities subsystem50that allow server system11to properly function.

Still referring toFIG. 2, utilities subsystem50further includes SINC device100, CLU device60and PM3device70. Each of these devices is considered a peer with respect to each other. Similarly, the service processor is also a peer with respect to each of the devices60,70and100. For example, and in accordance with the invention to be described in detail below, each device (SINC100, CLU60and PM370) can bi-directionally communicate with each other and with service processor200by using the USB20as a peer-to-peer network. In this example, the USB could be considered a LAN.

In accordance with an aspect of the invention, message logic150contained within SINC device100, CLU device60and PM3device70cooperates with the device to allow each device to prepend a unique communication protocol header to a block of data, thereby forming a communication message that is uniquely addressed to another device connected on the USB. The unique communication protocol header and the data (i.e., the communication message) are then encapsulated by a standard USB header and trailer and forwarded over the USB. The unique communication protocol header allows each device to communicate with each other device as if each device were connected to a peer-to-peer network.

SINC device100includes executive101, message logic150, USB driver102, hardware interface104and USB device controller106. USB device controller106is a hardware element that comprises a USB device interface chip and interfaces with USB driver102in order to communicate messages via USB20. Hardware interface104allows the executive101to communicate with other hardware elements (not shown) present on the SINC device100. Message logic150(to be described below in further detail), in cooperation with executive101, allows SINC device100to send a message to any other device connected to USB20by creating and prepending the above-mentioned unique communication protocol header to the data that the device wishes to send.

When used conventionally, the USB is useful only for communicating messages between a host and individual remotely connected devices. For example, in a personal computer (PC) environment, the USB is used to communicate messages between the processor and remotely connected peripheral devices such as a printer, a mouse and a keyboard. For example, there was no way (and no reason) for the mouse to communicate with the printer. In previous applications, the USB only allowed host-to-device communication.

In accordance with an aspect of the invention, the message logic150, in cooperation with USB router218, analyzes the unique communication protocol header and allows peer-to-peer communication between any devices connected to the USB20, thereby allowing the USB20to function as a peer-to-peer network.

CLU device60includes executive61, message logic150, USB driver62, hardware interface64, scan interface67and USB device controller66. Similarly, PM3device70includes executive71, message logic150, USB driver72, hardware interface74and USB device controller76. The executives61and71, USB drivers62and72, hardware interfaces64and74, and USB device controllers66and76all operate in similar fashion to their respective devices in SINC device100.

Although omitted fromFIG. 2for simplicity, the service processor200, SINC device100, CLU device60and PM3device70each include the processors, memory (including random access memory (RAM) and read-only memory (ROM)), interfaces and connections necessary to execute the software portions of the invention.

PROTOCOL STACK VIEW OF INVENTION

FIG. 3is a schematic view illustrating a protocol stack300according to one aspect of the invention. Service processor200includes USB host controller226, USB host driver224and USB router218.

SINC device100includes USB device controller106, USB device driver102and message logic150. As shown inFIG. 3, USB host controller226communicates with USB device controller106via physical connection (USB)20. USB host driver224communicates logically with USB device driver102via logical connection321. USB router218communicates logically with message logic150via pipes111,112and114using the communication protocol associated with the invention.

FIG. 4is a schematic view illustrating the message format330in accordance with the invention. Message format330includes USB header331, communication protocol header355, data360and USB trailer332. In accordance with an aspect of the invention, communication protocol header355, to be described in greater detail below, is prepended (attached before) to data360by any of the devices, for example, SINC device100, CLU device60, PM3device70and service processor200described above, resulting in communication message350. A standard USB header331and trailer332encapsulate the communication message350. In this manner, any of the individual devices connected to the USB20can send a uniquely identified message to any other of the devices connected to the USB20.

SYSTEM OPERATION

FIG. 5is a block diagram illustrating the connectivity between service processor200and SINC device100of FIG.2. AlthoughFIG. 5illustrates only one device (i.e., SINC device100) connected via USB20to service processor200, it is contemplated that many such devices are connected to service processor200. To illustrate the operation of the invention, and by way of example, firmware update module211(although any module inFIG. 2can also send a message), sends a communication message to USB router218via connection266. The message sent via connection266includes communication protocol header355and data360, which message is received by the USB router218. The communication protocol header355and the data360will be described in further detail below with respect to FIG.7. The USB router218inspects the message received via connection266and, by analyzing the communication protocol header355appended thereto, decides where to send the message. For example, the message from the firmware update module211could be destined to any other device connected to the USB, such as for example but not limited to the SINC100, CLU60and PM370. The USB router218is connected to a plurality of device drivers251,252and254. Device driver251is associated with SINC device100. Device driver252is associated with CLU device60and device driver254is associated with PM3device70. Provision of a device driver for each device type allows for prioritization between messages going to different device types. However, a single device driver could service all device types. The preferred implementation includes one device driver in the service processor200associated with each connected device type (i.e., SINC device100, CLU device60and PM3device70). These device drivers251,252and254are shown by way of example only.

Depending on the destination of the message received via connection266, the USB router218will provide that message to the appropriate device driver251,252or254, if the message is destined for the SINC device100, CLU device60or the PM3device70, or to another entity on the service processor200if addressed thereto. By way of example,FIG. 5includes SINC device100, which for example purposes only, will be assumed to be the device to which the message received via connection266is addressed. USB router218recognizes that the message received via connection266is destined for SINC device100and provides it to device driver251. When a message is received in service processor200from the SINC device100, that message would also appear in device driver251. In such a case, that received message is forwarded to USB router218, which, in accordance with an aspect of the invention, analyzes the communication protocol header prepended to that message and determines where to send that message. For example, if the SINC device100sent a message to the CLU device60, the message would appear at device driver251and would be forwarded to the USB router218, which would then provide the message to device driver252, associated with CLU device60. If the message received from the SINC100was destined for the service processor200, then the USB router218would accept the received message from device driver251and forward it, via connection262, to service processor incoming message handler250. Service processor incoming message handler250would remove the communication protocol header355and forward the data360to the appropriate module, in this example, the firmware update module211via connection264. Alternatively, the service processor incoming message handler250will forward the data360via connection267to any other appropriate application module, represented as other application modules268.

Returning again to the discussion of the message being sent from firmware update module211to the SINC device100, USB router218places the message in device driver251, which then queues the message in queue256. Device drivers251,252and254ofFIG. 5illustrate and correspond to device drivers220of FIG.2. The example given for illustrative purposes assumes that there is a single device of each described type (SINC, PM3and CLU). In practice, there would be multiples of each device type. Each instance of a given device type has its own queue within the device driver for that device type. Therefore, a device driver could handle a plurality of its device type by handling a plurality of queue-sets, each queue-set corresponding to a particular instance of the corresponding device type.

In accordance with the invention, a logical connection is established between service processor200and a remotely connected device, such as SINC device100. Arrows111,112and114, which are shown both in service processor200and in SINC device100, illustrate the concept of “pipes”, which represent the logical connection that exists between service processor200and SINC device100. Arrow111represents the bulk-out pipe, arrow112represents the interrupt-in pipe, and arrow114represents the bulk-in pipe. The concept of pipes is well known in the art of USB bus communications systems and corresponds to the concept of connected sockets in a transmission control protocol/Internet protocol (TCP/IP) network stack.

INCOMING MESSAGE OPERATION EXAMPLE

In accordance with an aspect of the invention, the USB host controller226and service processor200periodically poll, via the USB device controller106within SINC device100, the interrupt-in pipe112. If the SINC device100has data it wishes to send either to the service processor200or to another device connected to the USB20, the communication protocol header355that was prepended to the data360by the device is placed in queue156. Queue156resides within device outgoing message handler152, which places the communication protocol header355on the interrupt-in pipe112. When the USB host controller226polls the interrupt-in pipe112, it recognizes the presence of the communication protocol header355on the interrupt-in pipe and is thereby alerted that the SINC device100has information it wishes to send. The communication protocol header355will then be forwarded from the device outgoing message handler152through the interrupt-in pipe112to SINC device driver251. In USB industry standard terminology, the communication protocol header355is called an interrupt data packet.

The SINC device driver251will read the length of the communication protocol header355plus data field360by reading the length field of the header355(bytes6&7to be described below in FIG.7). The SINC device driver251will determine whether there is any more data that the SINC device100has to send. This is accomplished by analyzing particular fields within the communication protocol header355, which will be described in detail below with respect to FIG.7. If the SINC device driver251determines that the SINC device100has more information to send, the SINC device driver251will send a “USB bulk read” command to the SINC device100. This results in the balance of the communication message (i.e., the data360) being forwarded from the device outgoing message handler152through the queue158and then to the service processor200through bulk-in pipe114. Importantly, although described as being transferred via the pipes111,112and114, it should be noted that the pipes are logical connections, and that the transfer of the information actually occurs via the USB20.

In accordance with this aspect of the invention, and for the above described exchange to have taken place, the device outgoing message handler152will have received a message from one of several software modules on the SINC100(e.g., the new messages block126, the firmware update routine119or the reset routine118). The module initiating the message will have prepended a communication protocol header355to the data360. The device outgoing message handler152will have then placed the communication protocol header355in queue156and placed the data360in queue158. Although described using reset routine118, firmware update routine119and new messages block126, the message to be sent from the SINC device100can come from any of a number of different sources resident, and not shown, on the SINC device100.

In accordance with an aspect of the invention, the device driver251will read from the interrupt-in pipe112by using a “read” call. The concept of a call is understood by those having ordinary skill in the art. The call will remain pending if there is no message in the interrupt-in pipe112. The call will return if the USB host driver224detects a communication protocol header355in the interrupt-in pipe112. The device driver251will then remove the communication protocol header355from the interrupt-in pipe112and if the communication protocol header355indicates that there is data360associated therewith, the device driver251will post a read call at the bulk-in pipe114. This read call will remain pending until the read is completed.

OUTGOING MESSAGE OPERATION EXAMPLE

The transfer of an outgoing message (that is, a message sent from the service processor200to a remote device, such as SINC device100) will now be described. A message to be processed by the service processor200will either originate at the service processor200or may originate in another device (such as SINC device100) connected to the USB20. In accordance with the invention, the USB router218will queue an outbound message in one of the queues256,257or258associated with the device to which the message is addressed. In this example, the USB router218will pass the message to device driver251, which will queue a message in queue256for eventual transmission to SINC device100. If there are no messages currently in the process of being sent to SINC100, the device driver251will immediately extract the message from queue256and send the message to the SINC device100. If there is a previous outgoing message being sent, the new message will be retained in queue256and will be retrieved and sent to the SINC device100when a “send complete” interrupt for the earlier message occurs. The message sent from the USB router218through the bulk-out pipe111is then received into the device incoming message handler151and placed into queue154. Using “function calls” as known in the art, the executive101periodically calls, or polls, via connection109, the device incoming message hander151to determine whether there is a message present in queue154. The executive101performs other function calls as well. For example, the executive101periodically calls the hardware interface104via connection103to determine the status of the hardware on the SINC device100. The hardware interface104can also communicate with message logic150via connection108if it has any information to send to any other device connected on the USB20. If the device incoming message handler151has any information in the queue154, then upon being polled by the executive101, the device incoming message handler151will generate the appropriate function call in order to execute the message that is present in queue154.

For example, assuming that the firmware update module211has sent a firmware update message via the USB20to the SINC device100, when the device incoming message handler151detects this message in queue154, it will execute the appropriate function call via connection117to execute firmware update routine119. This firmware update is shown for illustration purposes only. Other messages will invoke different routines. Alternatively, the device incoming message handler151may have received a reset command, in which case it will execute a function call via connection116to reset routine118, which via connection127, will send a reset command to the reset hardware128.

There are a number of different scenarios in which the SINC device100will send a message to another device located on the USB20or to the service processor200.

For example, upon execution of the firmware update routine119in response to the firmware update message received from firmware update module211, the firmware update routine119could send either or both of an acknowledgement of the receipt of the message and a message indicating success or failure of the action requested in the message. This can be accomplished by the communication protocol header355to be described with respect toFIGS. 7 and 8. Alternatively, an unsolicited status update message can be sent from the SINC device100via new messages block126. As another example, the new messages block126could send a message to the PM3device70, which is a power monitor, informing it of the SINC's power requirements.

Regardless of the manner in which a message is provided, the device outgoing message handler152will analyze the message, which includes the communication protocol header355and data360, and will place the header355in queue156and place the data360in queue158. In accordance with the invention, the communication protocol header355is prepended to the data360by whichever device sent the message. For example, if the firmware update routine119was instructed to reply to the message received from the firmware update module211, the firmware update routine119would prepend the communication protocol header355, in accordance with that to be described below, to the message and deliver the header and the message to the device outgoing message handler152. The communication protocol header355prepended by the firmware update routine119identifies the service processor200as the destination for the message. When firmware update module211sent the message to which firmware update routine119is now responding, it would have put a unique number in the private area of the header (bytes8-11to be described below in FIG.7). This unique number is opaque to firmware update routine119, but is an identifier, which allows service processor incoming message handler250to identify firmware update module211as the intended recipient of the response message. When firmware update routine119built the response message, it would copy the private bytes362,364,366and367(FIG. 7) from the request message to the response message. The use of the private area of the message header is discussed below with respect to FIG.7.

The device outgoing message handler152places the communication protocol header355into the interrupt-in pipe112corresponding to queue156and will place the data360, if any is present, in the bulk-in pipe114associated with queue158. The queue156is a double buffered queue, corresponding to the USB device controller106, which is double buffered.

FIG. 6is a diagrammatic view illustrating the pipes ofFIG. 3implemented as queues in FIG.5. As shown, router218and SINC device100are connected via bulk-out pipe111, interrupt-in pipe112and bulk-in pipe114.FIG. 6illustrates the pipes as individual paths through which messages are exchanged. It should be noted that although shown as three individual pipes inFIG. 6, the pipes all exist on USB20.

MESSAGE HEADER FORMAT

FIG. 7is a schematic view illustrating an example of the communication message350of the message format330of FIG.4. Communication message350includes communication protocol header355and data360. Communication protocol header355includes 12 bytes of information. The bytes need not necessarily occur in the order shown. The destination cabinet number351(byte0) contains information regarding the destination cabinet number.

The destination address352(byte1) is the address within a cabinet of the device to which the message is destined. The cabinet number, together with the destination address352(byte1), identifies the device (i.e., the SINC device100, CLU device60and PM3device70) by assigning a unique device number to each device connected to the USB20.

Source cabinet number354(byte2) is the source cabinet number (i.e., the number of the cabinet containing the device that originates the message) and the source address356(byte3) is the address within a cabinet of the device sending the message). The destination address and the source address within a cabinet are shown below in Table 1.

The addresses given in Table 1 are arbitrary in that any unique values could be used. The fact that the name space is predefined means that devices cannot take on arbitrary names. There is preferably a predefined overall naming scheme by which a device can know its own name (address) and the name (address) of any device with which it may communicate. Alternatively, a directory service may take the place of such a naming scheme.

The command byte357(byte4) instructs the receiving module how to handle the message. Some implementation specific examples of commands and values used in the preferred embodiment are given below.

The command meanings and values are determined by the implementation details of a system constructed in accordance with the invention.

Flags byte358(byte5) represents the flags, which will be described in greater detail below with respect to FIG.8. Message length359(byte6) represents the message length (least significant byte) and message length361(byte7) represents the message length (most significant byte). The message length is the number of bytes in the message, including the 12 bytes of message header355. An incoming message handler can determine whether there is a data portion360of a message350by checking whether the message length is greater than 12 bytes.

Bytes8362through11367represent private data which identifies the software module (firmware update module211in this example) that initiated a request which requires a response. Any module in a device (e.g. firmware update module211in service processor200) which expects another device (e.g. SINC device100) to respond to a message it sends places an identifier, thereby identifying itself, in the private area of the header in bytes362,364,366,367. The responding module in the responding device (e.g. firmware update routine119in SINC device100) is required to copy the contents of the private area into the response message.

The identifier in the private area is a value, which the incoming message handler on the initiating device (e.g. service processor incoming message handler250on service processor200) can recognize as the destination module for the response (e.g. firmware update module211response queue). The identifier could be, for example, the identifier of a response queue for, or the address of, a function to call in the module that sent the original request. The service processor incoming message handler250directs all responses to the specific module based on the contents of the private area (bytes8through11in header355).

To illustrate addressing, the source and destination bytes351,352,354,356shown inFIG. 7identify the device. If the message is a command (initiated by a module), and if there is more than one command processing module on the destination device, the contents of the command byte357(byte4) can identify the specific module within the device that is to process the given command. If a message is a response (initiated in response to a command previously received), the contents of the command byte357(byte4), together with the contents of the private area bytes362,364,366and367(bytes8-11), identify the specific module to which the response is to be passed. The contents of the command byte357(byte4), together with the contents of the private area bytes362,364,366and367(bytes8-11), can also enable a module which has multiple requests outstanding to different devices to tie the response from each back to the outstanding request.

Message format350also includes data360, which includes optional command data bytes368and369(bytes12through byte length+11) of the message format350. Optional command data includes optional data. Data360is a variable length field containing 0 or more bytes of data. This data pertains to the particular command in the command byte357(byte4). For example, if the command was “Program EPROM Sector”, the data portion of the packet would be the data to program into the EPROM sector. If the command was “Status Response” and the packet was being sent as a result of a previous “Status Query” message, the data portion would be the actual device status.

FIG. 8is a schematic view illustrating the flag byte358(byte5) of FIG.7. As shown, flag byte358represents the flags format in which the bits4-7include message identification information and bits0and1can be set depending on the response desired from an individual device, such as SINC100connected to the USB20. For example, if the least significant bit (LSB)0is set to a logic “0” it indicates that the SINC device100ofFIG. 5is not to acknowledge receipt of a message sent to it. If the LSB0is set to a logic “1” then it signifies that receipt of the message should be acknowledged by the receiving device (i.e., the SINC100in the example described above with respect to FIG.5). Similarly, if the bit1of flag byte358(byte5) is set to a logic “0”, it indicates that success or failure of the command contained in the message need not be reported back to the originator of the message. Similarly, if the bit1is set to a logic “1”, then the sending device is indicating that success or failure of the command contained in the message is to be reported back to the originating device.

INITIALIZATION

Referring back toFIG. 5, as part of standard USB initialization, the USB host driver224enumerates (assigns an address to) each device (i.e., SINC device100, CLU device60, etc.) as that device becomes connected to the bus. (Note that this is a physical layer address, which is different from the logical layer address shown in Table 1.) The device, at that time, returns a device descriptor to the host. The device descriptor identifies the device type. This is well known by those having ordinary skill in the art of USB communications. At this time, the device in the preferred embodiment reports that it is, for example, a PM370, a CLU60or a SINC100. It also reports its specific address (e.g. SINC100in Cabinet0, SINC number2), using the encoding shown in Table 1. This allows the USB host driver224to initialize the appropriate queues (e.g. queue256, and pipes112and114) for this particular device.

The address of the device given in Table 1 is synonymous with its name. It is possible to consider a scheme where the address of a given device type and number is not fixed, but assigned dynamically. Such a scheme may be desirable if the mix of device types needs to be more flexible. If such a system were designed, it should still have the concept of a “name” for a device, in order that other entities could address that device. However, in such a case, there would preferably be a directory service so that any device could obtain the address corresponding to a name. The concept of a directory service is well known to those skilled in the art of networking.

It will be apparent to those skilled in the art that many modifications and variations may be made to the preferred embodiments of the present invention, as set forth above, without departing substantially from the principles of the present invention. For example, the present invention can be used in any system in which a number of devices communicate over a USB. All such modifications and variations are intended to be included herein within the scope of the present invention, as defined in the claims that follow.