Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing – Computer-to-computer data transfer regulating
Reexamination Certificate
2000-01-31
2004-05-18
Follansbee, John (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
Computer-to-computer data transfer regulating
C709S231000, C709S234000, C709S246000, C370S463000, C370S466000
Reexamination Certificate
active
06738823
ABSTRACT:
TECHNICAL FIELD
The present invention relates generally to the use of serial buses as a means of communication between electronic devices and, in particular, to the transmission of asynchronous data using isochronous packets across a serial bus, such as a serial bus operating in conformance with the IEEE 1394 Serial Bus Standard.
BACKGROUND OF THE INVENTION
Computer systems are typically comprised of a variety of different components or devices that operate together to form the resultant system. Some of the devices are supplied with the computer system initially, such as the central processing unit, and some devices can be installed into the computer system after the initial configuration of the system. The devices of the computer system are generally coupled together via interconnects which may be of several types, such as a serial bus.
Serial buses are well known in the art. A recently developed serial bus standard is the IEEE 1394 serial bus standard, disclosed in the ISO/IEC 13213 (ANSI/IEEE 1212) CSR Architecture Specification and the IEEE 1394-1995 Serial Bus Specification, the teachings of which are herein incorporated by this reference. A typical serial bus having an IEEE 1394 standard architecture is comprised of a multiplicity of nodes that are interconnected via point-to-point links, such as cables, that each connect a single node of the serial bus to another node of the serial bus. Each node is an addressable entity that can be reset and identified. Nodes are associated with respective components of the computer system and serve as interfaces between the components and communication links.
An IEEE 1394 compliant serial bus supports two types of packet transmission: asynchronous and isochronous. Asynchronous transmission is a form of communication that is not synchronized by a shared signal such as a clock. The data transmission may start at any time and is only throttled by how fast the sender can arbitrate for the bus. The characters are sent independent of each other and are separated by arbitrary intervals. To ensure that packets are not lost, asynchronous transmissions are automatically acknowledged by the receiver of the transmission. The acknowledgement lets the sender know that the receiver has received the request and will be sending a response. Likewise, when the receiver responds to the request, the original sender then sends an acknowledgement to let the original receiver know the response was received. Each acknowledgement generates additional traffic on the serial bus, thus reducing the effective bus bandwidth.
Isochronous transmission is a form of data transmission that can provide data at guaranteed intervals at a certain minimum data rate. This type of transmission is especially suitable for multimedia or time-dependent data such as audio or video because these types of transmissions need to arrive at close to the same rate of data flow as the source, whether it is from a peripheral device or from a network. A digital video camera is one example of a peripheral device that could use isochronous data transfer to feed digital image data to a computer. Isochronous transmission ensures a continuous and steady rate of transfer close to the ability of the receiver to accept and display the data. Isochronous transmissions are not automatically acknowledged by the receiver. Standard Ethernet cannot support isochronous traffic because other traffic may prevent the isochronous transmission from being carried. On Ethernet, the other traffic, or packets, may collide with the isochronous transmission destroying the packets.
There are many high level protocols used over a 1394 serial bus, such as server message block (SMB), or Novell Core Protocol (NCP), which ensure packet delivery at higher protocol levels. When using such protocols, transmitting packet acknowledgements at the bus level is redundant because the response itself is an implicit acknowledgement of the request.
Currently, when a high level protocol performs operations using a guaranteed delivery IEEE 1394 primitive like asynchronous read/write/lock, each request or response to request that is received is automatically acknowledged for receipt. A primary example is communication between a redirector and a server. A redirector is a software entity which allows a personal computer (PC) to see files and/or services of a remote computer. Normally, a redirector would use asynchronous transmission for data requests to a server. A server is a software entity which shares its local files and/or services to a redirector across a medium like a network. In
FIG. 1
, for example, at step
2
, a redirector sends a read request to a server in an asynchronous manner. Upon receiving the request, the server sends, at step
4
, an acknowledgement for receiving the request to the redirector. In other words, the server “acks” receipt of the request. Then at step
6
, the server sends the response to the request. The redirector, upon receiving the response, then sends, at step
8
, an acknowledgement for receiving the response to the original read request. In this manner, four messages (a request, a response and two acknowledgements) are transmitted for a simple read request. The two acknowledgement packets use up valuable bandwidth on the bus, thus reducing throughput.
A more detailed illustration of the process is shown in FIG.
2
. At the redirector, a request
10
, the path of which is shown as a solid line, is sent to the guaranteed delivery function
12
within the high-level message protocol
14
. The request
10
is then transferred to the asynchronous delivery function
16
within the 1394 protocol
18
. The asynchronous delivery function
16
sends the request
10
to the asynchronous transmitter
20
which then sends the request
10
across the serial bus
22
. There is also present within the 1394 protocol
18
an isochronous delivery function in communication with an isochronous transmitter, but these will not be discussed here as they are not within the path of the request
10
. At the server, the receiver
24
within the 1394 protocol
26
receives the request
10
and forwards the request
10
to the asynchronous delivery function
28
.
The asynchronous delivery function
28
, upon receiving the request
10
, generates an acknowledgement (ACK)
30
to acknowledge the receipt of the request
10
. The path of the ACK
30
is shown by an uneven dashed line. The ACK
30
is sent to the asynchronous transmitter
32
within the server which in turn sends the ACK
30
across the serial bus
22
. The receiver
34
within the 1394 protocol
18
of the redirector receives the ACK
30
and forwards the ACK
30
to the asynchronous delivery function
16
. As the asynchronous delivery function
28
of the server generates the ACK
30
, it also sends the request
10
to the guaranteed delivery function
36
within the high-level message protocol
38
. The request
10
is then passed on up the chain where a response is generated.
At the server, a response
40
, the path of which is shown as an even dashed line, is sent to the guaranteed delivery function
36
within the high-level message protocol
38
. The response
40
is then transferred to the asynchronous delivery function
28
within the 1394 protocol
26
. The asynchronous delivery function
28
sends the response
40
to the asynchronous transmitter
32
which then sends the response
40
across the serial bus
22
. There is also present within the 1394 protocol
26
an isochronous delivery function in communication with an isochronous transmitter, but these will not be discussed here as they are not within the path of the response
40
. At the redirector, the receiver
34
within the 1394 protocol
18
receives the response
40
and forwards the response
40
to the asynchronous delivery function
16
.
The asynchronous delivery function
16
, upon receiving the response
40
, generates an acknowledgement (ACK)
42
to acknowledge the receipt of the response
40
. The path of the acknowledgement
42
is shown by an uneven dashed line as is the path of the ACK
Banner & Wifcoff, Ltd.
Follansbee John
Lin Kenny
Microsoft Corporation
LandOfFree
Use of isochronous packets to eliminate redundant... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Use of isochronous packets to eliminate redundant..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Use of isochronous packets to eliminate redundant... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3232086