US20060126652A1 - Point-to point protocol - Google Patents

Abstract

A Point-to-point protocol configured to provide communication exchange between a first device and a second device. The point-to-point protocol is configured to negotiate an exchange rate and establish a connection for the communication exchange between the first and second device. As system dynamics change, the point-to-point protocol is also configured to permit application programs in the first device and the second device to request renegotiation of the exchange rate at any time. The point-to-point protocol is also configured to provide confirmation to a sending application program that information was delivered to a receiving application program.

Description

FIELD OF THE INVENTION
• The invention is related to the field of communications, and in particular, to a protocol for point-to-point communications between a pair of devices.
BACKGROUND OF THE INVENTION
• There exist numerous protocols defining rule sets that govern communication between devices. These protocols identify a common language and basic functionality, such as, routing, error detection, error correction, addressing, and the order in which the devices communicate with each other.
• One example of such a protocol is the Infrared Data Association (“IRDA”) protocol. The IRDA protocol defines a link protocol for serial infrared links. The IRDA protocol sets forth a common set of rules that devices operate in accordance with to communicate over a wireless air interface using infrared light. The IRDA protocol defines basic functionality such as link initialization, device address discovery, connection start-up, including link negotiation, information exchange, disconnection, link shutdown, and device address conflict resolution.
• Operationally, application programs located on two different devices can interact and communicate with one another using an IRDA port and the rules defined by the IRDA protocol. The application programs contain functions for particular application services, such as file transfer, remote file access, and virtual terminals. A service access method provides the interface between the IRDA protocol layer and the application program layer. The communications are provided to the service access method by the applications in the application program layer. The data input to the service access method is modulated into infrared signals by an infrared modem and exchanged over the IRDA port with another similarly configured device according to the rule set defined in the IRDA protocol. The receiving device demodulates the data and provides the data to an application program in its own application program layer.
• Another type of protocol used in communication between devices is a transmission control protocol/Internet protocol (“TCP/IP”). TCP/IP is a networking protocol that provides communication across interconnected networks between computers with diverse hardware architectures and operating systems. Operationally, TCP/IP messages from an application program layer of one device are divided into smaller segments called packets. The packets each include a sequence number that indicates the order of the segment within the message. The destination device receives and checks the packets for error conditions. If no error condition exists, the packets are routed to the application layer and the receiving protocol layer provides an acknowledgment message to the sending protocol layer confirming the packet receipt.
• Unfortunately, prior art protocols such as the IRDA and TCP/IP protocol do not provide flexibility in the exchange rate for communications between devices. Rather the exchange rate is set by the modulation/demodulation scheme defined by the device hardware. Thus, if the dynamics of the system change, inefficiency in the utilization of system resources could result. For example, if an application program needs to exchange a large communication, and the system is operating at a 20% resource utilization, the application program cannot utilize the available resources to transfer the communication at a faster exchange rate, but rather, is limited to the exchange rate defined in the device hardware, while the remaining 80% of the resources remain idle.
• Another problem with prior art protocols is that the acknowledgment message is received by the sending protocol layer and not the sending application program. The sending application program does not have knowledge that a communication was received. Thus, if the sending protocol layer does not receive the acknowledgment message, the application program does not have knowledge of the condition until a time-out error condition occurs. This results in synchronization errors as application programs in one device continue to send information to another device without knowledge of an error condition until a time-out error occurs.
SUMMARY OF THE INVENTION
• The present point-to-point protocol advances the art by providing a protocol that negotiates an exchange rate for communications between a pair of devices and permits the application program layer of either device to request renegotiation of the exchange rate at any time. The present protocol also provides a confirmation to the sending application program layer that an acknowledgment message was received.
• According to the present protocol, an exchange rate for communications between devices is automatically negotiated by the protocol and a connection established during an initialization process invoked during device start-up. As system dynamics change, the initialization process may be re-invoked at any time by an application program to renegotiate the exchange rate over the connection. Additionally an application can request a higher or lower exchange rate depending on the requirement of the requesting application program. Furthermore, the initialization process may also be re-invoked by the protocol layer in response to unrecoverable errors that occur during communication exchange.
• During a renegotiation of the exchange rate, an application program suggests a desired exchange rate to the protocol layer. Typically, the suggested exchange rate is the highest exchange rate currently supported by the device. The protocol layer provides a synchronization request message that includes the suggested exchange rate to the other device's protocol layer. The other device's protocol layer responds with a synchronization acknowledgment message that includes an exchange rate that is equal to or lower than the suggested exchange rate provided in the synchronization request message. Typically, the exchange rate provided in the synchronization acknowledgment message is the highest exchange rate currently supported by the other device that is equal to or lower than the suggested exchange rate. Advantageously, this permits application programs to suggest the highest possible exchange rate currently supported between two devices.
• Responsive to renegotiating the exchange rate, the protocol layers test the exchange rate to confirm that the connection supports the renegotiated exchange rate and provides reliable communication exchange between the devices. The testing confirms the reliability of providing multiple transmissions over the connection at the renegotiated exchange rate. If during testing, the protocol layer determines the connection cannot support multiple transmissions at the renegotiated exchange rate, the protocol layer again renegotiates the exchange rate to a lower reliable exchange rate. Advantageously, the testing permits applications to suggest higher exchange rates to the protocol layer, but does not allow an application to monopolize processing time and central processing unit resources allocated to the protocol layer. The present protocol merely allows applications to influence how the protocol utilizes allocated resources without turning over ultimate control of system resources. Also advantageously, the present protocol permits a system to be deterministic, in that it allows the applications, which have knowledge of the amount of central processing unit (“CPU”) and data bandwidth resources they require, to determine the quality of service by requesting the use of more or less of those resources. In other words the present protocol marries the two limiting factors in an information exchange system, namely, the bandwidth of the physical connection and the bandwidth of the CPU, and utilizes both efficiently.
• Another advantage of the present protocol is that the highest possible exchange rate is negotiated for the exchange of communications over a connection between a pair of devices. Another advantage of the present protocol is that it is not a master slave protocol, but rather, permits either device to initiate commands. Another advantage of the present protocol is that it includes a cyclic redundancy check (“CRC”) for error detection and reliable communication exchange. Another advantage of the present protocol is that the initialization process may be invoked at any time by an application program to re-negotiate the exchange rate. Another advantage of the present protocol is that the initialization process may also be invoked at any time by the protocol in response to error conditions or application's request. Another advantage of the present protocol is that a sending application program is notified when communications are received and acknowledged by the receiving device. Those skilled in the art will recognize additional advantages of the present invention by reference to the following figures and detailed description.
BRIEF DESCRIPTION OF THE DRAWINGS
• The same reference number represents the same element on all drawings.
• FIG. 1 illustrates a system architecture for the protocol according to the present invention;
• FIG. 2 is a message sequence chart illustrating one example of the operation of the protocol according to the present invention;
• FIG. 3 is a message sequence chart illustrating another example of the operation of the protocol according to the present invention;
• FIG. 4 is a software architecture for the protocol according to the present invention;
• FIG. 5 is an example of a fundamental message for the protocol according to the present invention;
• FIG. 6 is an example of payload fields for the fundamental message ofFIG. 5;
• FIG. 7 is an example of a supervisory message for the protocol according to the present invention;
• FIG. 8 is an example of an information message for the protocol according to the present invention;
• FIG. 9 is a logical diagram of messages and responses for the protocol according to the present invention;
• FIG. 10 is another logical diagram of messages and responses for the protocol according to the present invention; and
• FIG. 11 is a message sequence chart illustrating another example of the operation of the protocol according to the present invention.
DETAILED DESCRIPTION
• System Configuration and Operation FIGS.1-3:
• The present point-to-point protocol is configured to provide reliable communication exchange between a pair of devices. Advantageously, the present protocol does not rely on a master slave relationship between devices, but rather, permits the initiation and exchange of communications by either device. The communications could be any type of digital communications with one example being packet communications. Also advantageously, the present protocol includes cyclic redundancy check (“CRC”) error detection to provide for reliable communication exchange between devices.
• The present protocol includes three primary message types, namely, unnumbered messages, information messages, and supervisory messages. As will become apparent from the following description, however, other messages such as time-out messages and link-reset messages are also used to implement the principles of the present invention.
• The unnumbered messages are used by the protocol to negotiate the exchange rate and establish the connection for communications between the pair of devices. The unnumbered messages are also used to test the connection at the negotiated exchange rate by exchanging test messages in full duplex mode between the pair of devices. In the context of the present invention, the unnumbered messages are defined as messages that do not include a message sequence number.
• The information messages are used by the protocol to exchange communications between the devices. The communications could be any communications supported by the devices. Some examples of the communications include without limitation, voice, video and data communications. The information messages are acknowledged by supervisory messages provided by a receiving protocol layer back to a sending protocol layer. If a supervisory message is not received in response to the transmission of an information message within a pre-determined time-out period, the sending protocol layer re-transmits the information message to the receiving protocol layer. If a supervisory message is still not received after a pre-determined number of transmittal attempts, the initialization process is invoked and the exchange rate is renegotiated between the two devices.
• The supervisory messages are used by the protocol to acknowledge the receipt and validation of information messages and/or to provide error information. To acknowledge a proper receipt of an information message, a supervisory receiver ready message is provided in response to the information message. The supervisory receiver ready message includes a sequence acknowledgment for the next information message sequence number and indicates that the receiving device is ready for the next information message. To acknowledge an error in the receipt of an information message, a supervisory reject message is provided in response to the information message. If a receiver buffer is full, a supervisory receiver not ready message is provided in response to the information message. The supervisory receiver not ready message includes the sequence acknowledgement for the next information sequence number and indicates that the device is not ready to receive new information messages. The supervisory receiver not ready message is sent prior to a timeout message and is continuously sent until resources in the receiver buffer are freed.
• FIG. 1 depicts a pair of devices, namely, afirst device100 and asecond device101. Thefirst device100 comprises a point-to-point protocol layer102 according to the present invention and anapplication program layer104. Theapplication program layer104 comprises application programs106-108. Thesecond device101 comprises a point-to-point protocol layer103 according to the present invention and anapplication program layer105. Theapplication program layer105 comprises application programs109-111.
• The application programs106-111 could be conventional application programs running on thedevices100 and101. Those skilled in the art will appreciate that the application program layers,104 and105, could include numerous other application programs although only application programs106-111 are shown onFIG. 1 for clarity.
• The protocol layers,102 and103, could be any instructions that are stored on a storage media and are configured to automatically negotiate an exchange rate and establish a connection for the exchange of communications at the negotiated exchange rate between the devices,100 and101. The protocol layers,102 and103, are also configured to receive suggested exchange rates from the application program layers,104 and105, and renegotiate the exchange rate over the connection based on the suggested exchange rates received from the application program layers,104 and105. The protocol layers,102 and103, are also configured to test the renegotiated exchange rate to confirm that the connection supports the rate and provides reliable communication exchange between the devices,100 and101.
• The instructions could be retrieved and executed by one or more processors. Some examples of the instructions are Software, program code, and firmware. Some examples of storage media are memory devices, tape, disks, integrated circuits, and servers. The instructions are operational when executed by the one or more processors to direct the processors to operate in accord with the invention. The term “processor” refers to a single processing device or a group of inter-operational processing devices. Some examples of processors are integrated circuits and logic circuitry. Those skilled in the art are familiar with instructions, processors, and storage media.
• Operationally, the protocol layers,102 and103, perform an exchange rate negotiation and connection establishment during an initialization process invoked during device start-up. The initialization process is then re-invoked at the request of the application programs106-111 to renegotiate the exchange rate based on a suggested exchange rate provided to the protocol layers,102 and103, by the requesting one of the application program106-111. The protocol layers,102 and103, also invoke the initialization process in response to unrecoverable errors that occur during a communication exchange over the connection between thedevices100 and101.
• The devices,100 and101, could be any devices where point-to-point digital communication exchange is desired. Some examples of the devices,100 and101, include without limitation, tape drives, hard drives, tape library systems, notebook computers, desktop computers, and workstations.
• FIG. 2 is a message sequence chart illustrating one example of the initialization operation and a renegotiation operation according to the present invention. OnFIG. 2, the initialization process is invoked in the protocol layers,102 and103, when the devices,100 and101, are powered on. Responsive to the devices,100 and101, powering on, one of the protocol layers,102 and103, provides a synchronization request message to the other one of the protocol layers,102 and103, that includes at least one exchange rate. In this case, theprotocol layer102 provides the synchronization request message. The at least one exchange rate could be any exchange rate supported by thedevice100. For example, the at least one exchange rate could be a system default exchange rate for communications between the protocol layers,102 and103. The at least one exchange rate could also be a plurality of exchange rates supported by thedevice100.
• It should be noted that since the present protocol permits eitherdevice100 ordevice101 to initiate commands, either theprotocol layer102 or theprotocol layer103 could begin the initialization process as a matter of design choice. It should also be noted that the synchronization request and synchronization acknowledgment messages discussed in this example are unnumbered messages.
• Responsive to receiving the synchronization request message from theprotocol layer102, theprotocol layer103 processes the synchronization request message to generate a synchronization acknowledgment message for theprotocol layer102. The synchronization acknowledgment message includes an exchange rate supported by thedevice101, that is equal too or lower than the highest exchange rate provided by theprotocol layer102, and which becomes the negotiated exchange rate. For example, if the at least one exchange rate provided in the synchronization request message is a default for communication exchange between the protocol layers,102 and103, theprotocol layer103 returns the default exchange rate in the synchronization acknowledgment message. If the at least one exchange rate provided in the synchronization request message is a plurality of exchange rates supported by thedevice100, then theprotocol layer103 returns one of the plurality of exchange rates that is also supported by thedevice101.
• Responsive to receiving the synchronization acknowledgment message, the devices,100 and101, adjust their system settings to the negotiated exchange rate returned by theprotocol layer103. Responsive to negotiating the exchange rate, the protocol layers,102 and103, establish a connection between the devices,100 and101, to complete the initialization process.
• Responsive to the connection establishment, the application programs106-111 exchange communications over the connection at the negotiated exchange rate. Responsive to a change in system dynamics that causes an application program, e.g.106, to require a faster exchange rate, an exchange rate request message is provided to the device's protocol layer, e.g.102. For example, a large code update could cause theapplication program106 to desire a faster exchange rate.
• The exchange rate request message includes a suggested exchange rate for communication exchange over the connection. Responsive to receiving the exchange rate request message, theprotocol layer102 processes the request message to generate another synchronization request message for theprotocol layer103 that includes the suggested exchange rate. Theprotocol layer103 processes the synchronization request message to generate a synchronization acknowledgement message that includes an exchange rate that is equal to or lower than the suggested exchange rate, and which becomes the renegotiated exchange rate.
• To clarify, the suggested exchange rate provided in the synchronization acknowledgment message could be any exchange rate supported by thedevice101 that is equal too or lower than the suggested exchange rate provided in the synchronization request message. Typically, however, the exchange rate provided in the synchronization acknowledgment message is the highest exchange rate currently supported by thedevice101 that is equal to or lower than the suggested exchange rate. Thus, if theprotocol layer103 returns the suggested exchange rate in the synchronization acknowledgment message, then the suggested exchange rate becomes the negotiated exchange rate. If theprotocol layer103 returns a lower exchange rate in the synchronization acknowledgment message, the lower exchange rate becomes the negotiated exchange rate. In this way the protocol layers,102 and103, negotiate the highest common exchange rate between the devices,100 and101 based on an exchange rate suggested by theapplication program106.
• In a numeric example, if theprotocol layer102 provides a suggested exchange rate of 38400 kbps in the synchronization request message, theprotocol layer103 will return the highest rate supported by thedevice101 that is equal to or lower than the 38400 kbps supported by thedevice100. If theprotocol layer103 returns 38400 kbps in the synchronization acknowledgment message, the devices,100 and101, use 38400 kbps as the negotiated exchange rate. If theprotocol layer103 returns an exchange rate of 19200 kbps in the synchronization acknowledgment message, the devices,100 and101, use 19200 kbps as the negotiated exchange rate.
• FIG. 3 is a message sequence chart illustrating another example of the initialization operation and a testing operation according to the present invention. In this example, because both devices,100 and101, include the same program code and can initiate commands, both devices,100 and101, provide a synchronization request message and receive a corresponding synchronization acknowledgment message in response to a device start-up.
• OnFIG. 3 the operation begins when the devices,100 and101, are powered on. Responsive to thedevice100 powering on, theprotocol layer102 provides a synchronization request message to theprotocol layer103. In this example, the synchronization request message includes all of the exchange rates supported by thedevice100. Responsive to receiving the synchronization request message from theprotocol layer102, theprotocol layer103 processes the synchronization request message to generate a synchronization acknowledgment message for theprotocol layer102 that includes an exchange rate for thedevice101 that is equal too one of the exchange rates provided in the synchronization request message. The exchange rate returned in the acknowledgment message could be the highest common exchange rate between the devices,100 and101, or could be a default exchange rate for the devices,100 and101.
• Substantially simultaneously, theprotocol layer103 provides a synchronization request message to theprotocol layer102 that includes all of the exchange rates supported by thedevice101. Responsive to receiving the synchronization request message, theprotocol layer102 processes the synchronization request message from theprotocol layer103 to generate a synchronization acknowledgment message that includes the exchange rate provided by theprotocol layer103 in the synchronization acknowledgment message, and which becomes the negotiated exchange rate. Advantageously, however, the each protocol layer,102 and103, now has knowledge of all of the exchange rates supported by the other device.
• Responsive to negotiating the exchange rate, the protocol layers,102 and103, establish a connection between the devices,100 and101, and the devices,100 and101, adjust their system settings to the negotiated rate. Responsive to determining the negotiated exchange rate and establishing the connection, the protocol layers102 and103 test the connection between thedevices100 and101. During testing, the protocol layers,102 and103, each provide a series of test and acknowledgement messages as illustrated onFIG. 3. The test and acknowledgment messages are used to establish an error free connection between the devices,100 and101. Although those skilled in the art will appreciate that any number of test and acknowledgment messages could be used as a matter of design choice, in this case, five test messages are sent and acknowledged before the connection is declared ready for the exchange of communications.
• The test messages each include a data field having a byte sequence N+1, N+2, where N is the test message number. The test acknowledgement messages acknowledge the receipt and validation of the test messages by returning a data field that includes the data received in the test message. If during testing, one of the test or acknowledgment messages fail, the protocol layers,102 and103, automatically begin the initialization process to re-negotiate the exchange rate and the above steps are repeated until a reliable connection is established.
• It should be noted that in the above example, it is irrelevant which protocol layer begins the initialization process by providing the synchronization request message or begins the testing by providing the test message, but rather, only that each layer,102 and103, provides a synchronization request message, acknowledgment message, a test message, and test acknowledgment message to the other layer.
• Software Architecture:
• FIG. 4 depicts software architecture for thedevice100. Those skilled in the art will appreciate that the software architecture for thedevice100 is substantially similar to the software architecture for thedevice101 and therefore the architecture for thedevice101 is not shown to avoid redundancy. Thedevice100 comprisesports407,drivers406, theprotocol layer102, callback functions404, and theapplication program layer104. Theprotocol layer102 comprises a protocoltimer logic block400, a protocol statemachine logic block401, a receivebuffer402, and a transmitbuffer403.
• Theports407 could be conventional ports for the exchange of communications with other devices. In one example of the present invention, theports407 are conventional serial ports for serial communications between devices. Thedrivers407 could be conventional drivers that integrate with a host operating system and control the communication exchange between theports407 and theprotocol layer102. In one example of the present invention, the host operating system could be a commercial run-time operating system including a semaphore and some form of tasks. Alternatively, those skilled in the art will appreciate that other operating systems could be used as a matter of design choice.
• The callback functions404 are configured to provide communication exchange between theprotocol layer102 and theapplication program layer104. Operationally, each application program in theapplication program layer104 that processes information messages must register its source address and callback function with theprotocol state machine401 before receiving communications. Once registered, a sending application program sets the destination address, which determines where data is delivered. Advantageously, a single application program can register multiple destination addresses with theprotocol state machine401.
• Thestate machine401 maintains a table of source addresses and function pointers. The table is built through the registration process when an application program registers its source addresses with thestate machine401. Thestate machine401 uses the transmitbuffer403 to store messages to be sent to another application program layer, e.g.105. Thestate machine401 uses receivebuffer402 to store messages received for theapplication program layer104.
• Operationally, when thestate machine401 receives an information message from another device,e.g. device101, it looks up the destination address in the source address table and calls the appropriate one of the callback functions404 to deliver the information message to a receiving application program in theapplication program layer104. Thestate machine401 also provides a supervisory acknowledgement message back to the sendingprotocol layer103 to confirm receipt and validation of the information message. When thestate machine401 transmits an information message to another device,e.g. device101, it receives the destination address from the sending application program and delivers an information message to thereceiving protocol layer103. Upon receiving a supervisory acknowledgement message from theprotocol layer103 indicating the information message was received validated and delivered, thestate machine401 provides an acknowledgement to the sending application program the indicates that the information message was delivered to the receiving application program in thedevice101.
• Thestate machine401 uses thetimer400 following the transmission of an information message to theprotocol layer103. An acknowledgement message timer is started once thestate machine401 provides an information message. The timer is turned off once thestate machine401 receives a supervisory acknowledgement message from the receivingprotocol layer103. If the supervisory acknowledgement message from the receivingprotocol layer103 is not received before expiration of the timer, the information message is resent to theprotocol layer103. If an acknowledgement message is still not received after a pre-determined number of attempts, thestate machine401 provides a set response mode message to theprotocol layer103 that causes the protocol layers102 and103 to begin the initialization process and re-negotiate the exchange rate and re-establish the connection. While those skilled in the art will appreciate numerous methods of determining the timer period and number of attempts before a set response mode message is provided, in one example of the present invention, the time-out could be calculated as the maximum message size multiplied by the exchange rate multiplied by four. Additionally, the number of attempts made before an exchange rate renegotiation could be set at three.
• Fundamental Message Architecture FIGS.5-8:
• FIG. 5 depicts afundamental message500 for the protocol according to the present invention. The fundamental message comprises four fields beginning with a start of message (SOM)field501 and ending with an end of message (EOM)field504. Apayload field502 andCRC field503 for error detection are included between theSOM field501 andEOM field504. TheSOM field501 indicates the beginning position of thepayload field502 and initiates the error checking for themessage500. TheEOM field504 delimits the end of the CRC error checking and terminates themessage500.
• FIG. 6 depicts thepayload field502 of the fundamental message and the sub-fields that could be included in thepayload field502. It should be noted that the content of thepayload field502 is unrestricted and not all message types include all of the payload sub-fields shown onFIG. 6. As will become apparent from the following description, different message types, e.g. unnumbered, supervisory, and information message types include different payload sub-fields. Typically, however, thepayload field502 includes at least header information used by the protocol layers,102 and103, and the information to be transferred.
• Thepayload field502 could comprise one or more of adevice sub-field600, acontrol sub-field601, asource address sub-field602, adestination address sub-field603, amessage sequence sub-field604, a message acknowledgement sub-field605, alength sub-field606, adata sub-field607, and areserve sub-field608.
• The first payload sub-field for all types of messages, supervisory, unnumbered, or information, is thedevice sub-field600. Thedevice sub-field600 identifies the implementation version of the protocol.
• Thereserve sub-field608 serves as a placeholder to accommodate future implementation of the protocol and for the addition of other features in the protocol.
• Thecontrol sub-field601 defines the type of message, e.g. supervisory, unnumbered, information, or supervisory receiver ready, supervisory reject, or supervisory receiver not ready message.
• The source sub-field602 identifies the device, e.g.100, that provided the message. As will become apparent from the following description, the source sub-field602 includes a unique source address for the callback function that initiated a data transfer.
• Thedestination address sub-field603 is used for routing information messages to the appropriate application program. Thedestination address sub-field603 includes the destination address of the callback function that the data portion of thepayload field502 is intended for.
• Themessage sequence sub-field604, is included in information messages, and contains a sequence number that indicates the sequence of messages being transferred. In one example of the present protocol, the sequence numbers start at one and are incremented by one each time an information message is transmitted between the protocol layers,102 and103.
• The message acknowledgment sub-field605 is included in supervisory messages to acknowledge the receipt of an information message and contains the next message sequence number expected by the receiving protocol layer, e.g.102.
• Thelength sub-field606 contains the number of bytes in the data sub-field607. The data sub-field607 contains the raw data transferred in an information message. For example, in the case of an unnumbered message, e.g. synchronization request and response messages, the data sub-field607 includes at least one exchange rate.
• Supervisory MessageFIG. 7
• FIG. 7 depicts an example of asupervisory message700. Thesupervisory message700 comprises aSOM field501, apayload field502, aCRC field503, and anEOM field504. The payload filed502 for thesupervisory message700 comprises adevice sub-field600, acontrol sub-field601, amessage sequence sub-field604, and amessage acknowledgement sub-field605. Thedevice sub-field600 comprises a SOM flag704 and adata field607 for the raw data. Thecontrol sub-field601 indicates the type of supervisory message and comprises one of a receiver ready (RR)flag701, a reject flag (REJ)702 or a receiver not ready flag (RNR)703.
• Supervisory messages acknowledge the receipt and validation of information messages, or an error condition in the receipt of an information message. There are generally three types of supervisory messages although other supervisory messages could be utilized as a matter of design choice. The first type of supervisory message is the supervisory receiver ready message indicated by theRR flag701. The supervisory receiver ready message indicates that an information message was received, successfully validated, and delivered to an application program by a receiving protocol layer, e.g.103. The supervisory receiver ready message also indicates to the sending protocol layer, e.g.102, that the receivingprotocol layer103 is ready to receive additional information messages.
• The second type of supervisory message is the reject message indicated by the REJ flag702. The supervisory reject message is used by the receiving protocol layer, e.g.103, to indicate an error condition in the reception of an information message, such as a bad sequence number. The supervisory reject message also requests re-transmission of the last sent information message identified in themessage acknowledgment field605. In some examples of the present protocol, the supervisory reject message is only used when the message sequence number is unexpected. In this case the received information message is not delivered to the destination address, but rather, must be re-sent with the proper sequence number by the sending protocol layer, e.g.102.
• The third type of supervisory message is the receiver not ready message indicated by the RNR flag703. The supervisory receiver not ready message is used to indicate a temporary busy condition of a receiving protocol layer, e.g.103, caused by internal constraints that prevent reception of additional information messages. The supervisory receiver not ready message confirms the sequence and data integrity of the last sent information message. When the condition is cleared, the receivingprotocol layer103 provides a supervisory receiver ready message to the sendingprotocol layer102 to indicate that the sending of information messages can continue.
• TheCRC field503 includes the CRC error detection and data validation algorithm. The CRC is computed on the entire payload, excluding control flags. Operationally, CRC values are calculated using polynomial division. A polynomial is chosen to be the divisor. The data upon which the CRC is calculated serves as the dividend. The CRC is the remainder that is left once the division process is complete. The size of the CRC is dependent upon the polynomial divisor chosen. In one example of the present invention, the algorithm implements a two byte (16 bit) CRC. If a received information message contains CRC errors, the receiving protocol layer, e.g.102, deletes the received information message and thestate machine401 increments the statistic table for CRC errors.
• Information MessaaeFIG. 8:
• FIG. 8 depicts an example of aninformation message800. Theinformation message800 comprises aSOM field501, apayload field502, aCRC field503, and anEOM field504. The payload filed502 for theinformation message800 comprises adevice sub-field600, acontrol sub-field601, amessage sequence sub-field604, a message acknowledgement sub-field605, asource address sub-field602, adestination address sub-field603, alength sub-field606 and adata sub-field607. Thecontrol sub-field601 includes amessage flag800 and a final message flag801.
• Information messages transfer sequenced data between the devices,100 and101. The protocol layer in the receiving one of the devices,100 and101, acknowledges an information message, with a supervisory message. If the data to be transferred in an individual information message is greater than a maximum size of the data sub-field607, the data is transferred in multiple information messages. In this case, all information messages except for the last information message will include a final message flag801 set to zero to indicate that additional information messages will be provided. The final information message in a sequence includes a final message flag801 set to one to indicate the completion of a sequence of information messages.
• Additional Examples of Operation FIGS.912:
• FIG. 9 is logical diagram depicting the messages that could be received by the devices,100 and101, and the response messages or action taken by the devices,100 and101. It should be noted that the following description applies equally to the devices,100 and101, although thedevice100 is used as an example in the following discussion.
• OnFIG. 9, thedevice100 could receive an information message that cannot be validated by thestate machine401. The validation process could fail for numerous reasons. Some examples include without limitation, an unknown or unimplemented control field, a data field that exceeds the maximum raw data block size, a serial line error, or a CRC error. If an information message validation fails, thestate machine401 deletes the message from the receivebuffer402, increments the statistic table for the error, and waits for the timer in the sendingprotocol layer103 to time out. Once the timer times out, theprotocol layer103 retransmits the information message to thedevice100.
• Thedevice100 could also receive an information message that includes an unexpected sequence number. In this case, thestate machine401 provides a supervisory reject message to the sendingprotocol layer103 and awaits retransmission of the information message with the correct sequence number. The supervisory reject message also includes the sequence number expected by thestate machine401.
• Thedevice100 could also receive a time-out condition from thetimer400 during the receipt of an information message. Thetimer400 starts a receive timer at the detection of theSOM field501 in the information message. The receive timer is turned off at detection of theEOM field504. If a receive time-out condition occurs prior to theEOM field504, thestate machine401 ignores the received characters and waits for the information message to be re-sent by the sendingprotocol layer103.
• Thedevice100 could also receive an information message that is validated and deliverable. In this case, thestate machine401 provides a supervisory receiver ready or a supervisory receiver not ready message to the sendingprotocol layer103. Both of these messages contain a message acknowledgement number to acknowledge the receipt of a valid information message. The supervisory receiver ready message indicates that thestate machine401 is ready to receive another information message. The supervisory receiver not ready message indicates that thestate machine401 is not ready to receive additional information messages.
• Thedevice100 could also receive a test message provided during the initialization process. In this case thestate machine401 provides a test acknowledgment message to the sendingprotocol layer103 that includes a copy of the test data provided in the test message.
• Thedevice100 could also receive a reset message. A reset message indicates that a user is requesting that the connection be reset. Reset messages are not acknowledged, but rather, thestate machine401 enters the initialization process to re-negotiate the exchange rate and establish the connection between the devices,100 and101.
• Thedevice100 could also receive a synchronization request message during the initialization process. The synchronization request message indicates initialization of the connection. Thestate machine401 responds with a synchronization acknowledgment message indicating the renegotiated exchange rate. The synchronization request message could be generated during device start-up or in response to an unrecoverable error in the exchange of communications.
• Thedevice100 could also receive a message reject message. A message reject indicates that the last message sent by thedevice100 includes an unknown destination address and is undeliverable. The message reject message includes a cause, source address and destination address field. In this case thestate machine401 removes the undeliverable message from the transmitbuffer403 and provides an indication to the sending application program that the message is undeliverable.
• Thedevice100 could also receive an abort sequence message. The abort sequence message indicates a premature termination of a data transfer. In this case, thestate machine401 aborts the current reception and deletes any received data.
• FIG. 10 is logical diagram depicting the messages that could be received by one of the devices,100 and101, in response to the transmission of an information message. It should be noted that the following description applies equally to thedevice101.
• OnFIG. 10 thedevice100 could receive a synchronization request message in response to the transmission of an information message. Since the synchronization request message is not in response to a power on, the synchronization request message indicates that either the connection is down or an application program is requesting an exchange rate renegotiation. Any outstanding messages waiting to be sent are removed from the transmitbuffer403 and must be re-provided by the application programs layer405.
• Thedevice100 could also receive a supervisory receiver ready message in response to the transmission of an information message. Receiving this message indicates that the receivingprotocol layer103 has acknowledged and delivered to the registered application the last sent information message.
• Thedevice100 could also receive a time-out condition in response to the transmission of an information message. An acknowledgment message timer is started in thetimer400 when thestate machine401 transmits an information message. The timer is turned off when thestate machine401 receives a supervisory message with the correct acknowledgment sequence number. If the timer times-out before a supervisory acknowledgment message is received, thestate machine401 re-transmits the information message. If after a pre-determined number of attempts, the information message is still not acknowledged, thestate machine401 provides a synchronization request message to re-establish the connection and/or renegotiate the exchange rate.
• Thedevice100 could also receive a supervisory reject message in response to the transmission of an information message. The supervisory reject message indicates that an unexpected sequence number was provided in the last information message. The number of the message expected is also included in themessage acknowledgement field605 of supervisory reject message. If all retries are not exhausted, thestate machine401 re-transmits the information message. Otherwise thestate machine401 provides a synchronization request message to re-establish the connection.
• Thedevice100 could also receive a supervisory receiver not ready message in response to the transmission of an information message. The supervisory receiver not ready message indicates that theprotocol layer103 in thedevice101 is not ready to receive another information message. Thestate machine401 starts the acknowledgement timer and waits for the next response message. Theprotocol layer103 may send another supervisory receiver not ready message before the timer expires to reset the timer. Theprotocol layer103 could also provide a supervisory receiver ready message to thedevice100. In this case thestate machine401 re-sends the information message to thedevice101.
• Thedevice100 could also receive a message reject in response to the transmission of an information message. The message reject indicates that the last information message provided by thestate machine401 includes an unknown destination address. Thestate machine401 removes the information message from the transmitbuffer402 and provides an indication to the sending application program that the information is currently undeliverable.
• FIG. 11 is a message sequence chart illustrating additional operations of the protocol according to the present invention. OnFIG. 11 the initialization and test operation ofFIG. 3 is invoked in the protocol layers,102 and103, when the devices,100 and101, are powered on. Responsive to the connection establishment and testing, theapplication program108 provides a data message to theprotocol layer102 that includes data information for theapplication program110. Theprotocol layer102 generates and provides an information message that includes the data information for theprotocol layer103. Responsive to receiving the information message, theprotocol layer103 validates the information message and provides the data information to theapplication program110. Substantially simultaneously, theprotocol layer103 generates and provides a supervisory receiver ready message to theprotocol layer102. The supervisory receiver ready message indicates to theprotocol layer102 that the data was validated and delivered to theapplication program110. Responsive to receiving the supervisory receiver ready message, theprotocol layer102 generates a data acknowledgment message for theapplication program108. The data acknowledgement message indicates to theapplication program108 that the data was delivered to theapplication program110 by theprotocol layer103. Advantageously, the data acknowledgment message permits theapplication program108 to move on to the next task quicker while keeping thedevice100 and thedevice101 synchronized. Also advantageously, the data acknowledgment message provides auto-synchronization between thedevice100 and thedevice101 without the receivingapplication program110 providing a response message to theapplication program108 indicating receipt of the information.
• Responsive to a change in the system dynamics that causes theapplication program110 to require a faster exchange rate, an exchange rate request message is provided to theprotocol layer103. The exchange rate request message includes a suggested exchange rate for communication exchange over the connection. Responsive to receiving the exchange rate request message, theprotocol layer103 processes the request message to generate another synchronization request message for theprotocol layer102 that includes the suggested exchange rate. Theprotocol layer102 processes the synchronization request message to generate a synchronization acknowledgement message that includes an exchange rate that is equal or lower than the suggested exchange rate, and which becomes the renegotiated exchange rate. Responsive to renegotiating the exchange rate, the protocol layers,102 and103, test the connection by exchanging a series of test and acknowledgment messages in full duplex mode over the connection at the renegotiated exchange rate as shown inFIG. 3.
• If the testing operation fails, the protocol layers,102 and103, again invoke the initialization process to renegotiate the exchange rate to the next lower exchange rate. If the connection is confirmed, as illustrated inFIG. 11, theapplication program110 is allowed to provide a data message to theprotocol layer103 that includes data information for theapplication program108. Responsive to receiving the data information, theprotocol layer103 generates and provides an information message that includes the data information for theapplication program108. Responsive to receiving the information message, theprotocol layer102 validates the message and provides the data information to theapplication program108. Substantially simultaneously, theprotocol layer102 generates and provides a supervisory receiver ready message to theprotocol layer103 that indicates that the data was validated and delivered to theapplication program108. Responsive to receiving the supervisory receiver ready message, theprotocol layer103 generates a data acknowledged message for theapplication program110 that indicates that the data was delivered to theapplication program108 by theprotocol layer102. Theprotocol layer103 also provides the next information message to theprotocol layer102. Responsive to receiving the information message, theprotocol layer102 validates the message and provides the data information to theapplication program108. Substantially simultaneously, theprotocol layer102 generates and provides another supervisory receiver ready message to theprotocol layer103 that indicates that the data was validated and delivered to theapplication program108.
• In another example of the operation, if theprotocol layer102 could not validate an information message, theprotocol layer102 generates a supervisory reject message for theprotocol layer103 that causes theprotocol layer103 to retransmit the information message. The example of a supervisory reject message and the retransmission of the information message are indicated onFIG. 11 by dashed lines.
• In another example of the operation, if theprotocol layer102 was busy and could not receive additional information messages, theprotocol layer102 generates a supervisory receiver not ready message for theprotocol layer103 that causes theprotocol layer103 to pause the transmission of additional information messages until resources in theprotocol layer102 are freed. The example of the supervisory receiver not ready message is indicated onFIG. 11 by the dashed line.
• The above-described elements can be comprised of instructions that are stored on storage media. The instructions can be retrieved and executed by a processing system. Some examples of instructions are software, program code, and firmware. Some examples of storage media are memory devices, tape, disks, integrated circuits, and servers. The instructions are operational when executed by the processing system to direct the processing system to operate in accord with the invention. The term “processing system” refers to a single processing device or a group of inter-operational processing devices. Some examples of processing devices are integrated circuits and logic circuitry. Those skilled in the art are familiar with instructions, computers, and storage media.
• Those skilled in the art will appreciate variations of the above-described embodiments that fall within the scope of the invention. As a result, the invention is not limited to the specific examples and illustrations discussed above, but only by the following claims and their equivalents.

Claims (32)

1-41. (canceled)

42. A method for communicating between devices, the method comprising:

receiving, at a protocol layer of a first device, a suggested exchange rate from an application program;

sending a synchronization request message from the first device to a second device, the synchronization message including the suggested exchange rate;

receiving a synchronization acknowledgement message in the first device, the synchronization acknowledgement message including one of the suggested exchange rate and a second exchange rate as a negotiated exchange rate; and

sending communications to the second device over the connection at the negotiated exchange rate.

43. The method ofclaim 42, further comprising:

responsive to the negotiated exchange rate, establishing a connection between the first device and the second device.

44. The method ofclaim 42, further comprising:

adjusting a first device exchange rate to the negotiated exchange rate.

45. The method ofclaim 44, further comprising:

testing a connection between the first device and the second device at the negotiated exchange rate.

46. The method ofclaim 42, wherein the suggested exchange rate is a highest common exchange rate between the first device and the second device.

47. The method ofclaim 45, wherein testing the connection comprises:

exchanging full duplex test messages and test acknowledgment messages between the first device and the second device at the suggested exchange rate.

48. The method ofclaim 47, further comprising:

responsive to an error during testing, renegotiating the exchange rate between the first device and the second device to a lower exchange rate; and

sending further communications to the second device at the lower exchange rate.

49. The method ofclaim 42, wherein the step of sending communications to the second device further comprises

providing an information message to the second device that includes the communications;

receiving a supervisory response message from the second device acknowledging the information message.

50. The method ofclaim 49, wherein the supervisory response message indicates a validation of the information message.

51. The method ofclaim 49, wherein the supervisory response message indicates an error in the information message.

52. The method ofclaim 49, wherein the supervisory response message indicates the validation of the information message and a receiver not ready condition.

53. The method ofclaim 42, wherein the communications are packetized communications.

54. A method of facilitating communication between devices, the method comprising:

receiving, at a protocol layer of a first device, data from an application program;

generating an information message including the data;

transmitting the information message to a second device;

receiving, at the protocol layer of the first device, a supervisory message from the second device acknowledging the information message;

generating, responsive to the supervisory message, a data acknowledgement message indicating that the data was acknowledged by the second device; and

providing the data acknowledgement message to the application program.

55. The method ofclaim 54, further comprising:

sending a synchronization request message to a second protocol layer of the second device, the synchronization message including a first exchange rate;

receiving a synchronization acknowledgement message in the protocol layer of the first device, the synchronization acknowledgement message including one of the first exchange rate and a second exchange rate as a negotiated exchange rate.

56. The method ofclaim 55, further comprising:

receiving, at the protocol layer of a first device, the first exchange rate as a suggested exchange rate from the application program.

57. The method ofclaim 54, wherein the information message comprises a message sequence field and a data field, wherein the data field contains the data, and wherein the sequence field comprises a sequence number identifier corresponding to the data.

58. The method ofclaim 55, further comprising:

adjusting a first device exchange rate to the negotiated exchange rate.

59. The method ofclaim 54, further comprising:

testing a connection between the first device and the second device at the negotiated exchange rate.

60. The method ofclaim 59, further comprising:

responsive to an error during testing, renegotiating the exchange rate between the first device and the second device to a lower exchange rate; and

sending further communications to the second device at the lower exchange rate.

61. A communications apparatus, comprising:

an application programming layer comprising an application program; and

a protocol layer operative to

receive data from the application program;

generate an information message including the data;

transmit the information message to a destination device;

receive, from the destination device, a supervisory message acknowledging the information message;

generate, responsive to the supervisory message, a data acknowledgement message indicating that the data was delivered to the destination device; and

provide the data acknowledgement message to the application program.

62. The communications apparatus ofclaim 61, wherein the protocol layer is further operative to

send a synchronization request message to a second protocol layer of a second device, the synchronization message including a first exchange rate; and

receive a synchronization acknowledgement message from the second protocol layer of the second device, the synchronization acknowledgement message including one of the first exchange rate and a second exchange rate as a negotiated exchange rate.

63. The communications apparatus ofclaim 61, wherein the protocol layer is further operative to receive the first exchange rate as a suggested exchange rate from the application program.

64. The communications apparatus ofclaim 61, wherein the protocol layer is further operative to adjust an exchange rate implemented by the communications apparatus to the negotiated exchange rate.

65. The communications apparatus ofclaim 64, wherein the protocol layer is further operative to test a connection between the communications apparatus and the second device at the negotiated exchange rate.

66. The communications apparatus ofclaim 65, wherein the protocol layer is further operative to renegotiate the exchange rate between the communications apparatus and the second device to a lower exchange rate, responsive to an error during testing; and

send further communications to the second device at the lower exchange rate.

67. The communications apparatus ofclaim 61, wherein the protocol layer comprises:

a protocol state machine, a receive buffer and a transmit buffer.

68. The communications apparatus ofclaim 67, wherein the protocol state machine is operative to receive, from a second device, an information message intended for the application program; store the information message in the receive buffer; and

provide the information message to the application program.

69. The communications apparatus ofclaim 68, wherein the protocol layer is further operative to validate the information message; and

transmit, to the second device, a supervisory message acknowledging the information message.

70. The communications apparatus ofclaim 68, wherein the protocol state machine is operative to transmit to the second device a supervisory message indicating a receiver not ready condition, responsive to a receive buffer full condition.

71. The communications apparatus ofclaim 67, wherein the protocol state machine is operative to store the data received from the application program in the transmit buffer.

72. The communications apparatus ofclaim 61, further comprising a port for exchange of communications with the destination device.

Images