CA2246134C - Enhanced network protocol - Google Patents
Enhanced network protocol Download PDFInfo
- Publication number
- CA2246134C CA2246134C CA002246134A CA2246134A CA2246134C CA 2246134 C CA2246134 C CA 2246134C CA 002246134 A CA002246134 A CA 002246134A CA 2246134 A CA2246134 A CA 2246134A CA 2246134 C CA2246134 C CA 2246134C
- Authority
- CA
- Canada
- Prior art keywords
- computing device
- pdu
- pdus
- data
- packets
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/164—Adaptation or special uses of UDP protocol
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Abstract
A low latency network protocol for use with packet switched data networks is disclosed. In accordance with the protocol, a first computing device (l0a) forms protocol data units ("PDU"s) (50) containing data to be transmitted to a second computing device computing device (10b). Multiple PDUs grouped in sets, each containing identical data are transmitted to the second computing device at short intervals. At least one PDU (50) in each set is transmitted in a packet that conforms to a reliable protocol that requires acknowledgment of receipt of the packet. The remaining PDUs (50) are preferably transmitted in packets that conform to a protocol that does not require acknowledgement of the packets.
Transmission of multiple PDUs (50) containing identical data increases the likelihood that the data will be received with minimal delay. Transmitting at least one PDU (50) using a reliable protocol ensures data will be received. At the second computing device, PDUs (50) containing duplicate data are discarded.
Transmission of multiple PDUs (50) containing identical data increases the likelihood that the data will be received with minimal delay. Transmitting at least one PDU (50) using a reliable protocol ensures data will be received. At the second computing device, PDUs (50) containing duplicate data are discarded.
Description
ENHANCED NETWORK PROTOCOL
FIELD OF THE INVENTION:
The present invention relates to data network protocols, and more particularly to a low latency, packet based protocol.
BACKGROUND OF THE INVENTION:
Packet switched computer networks have become widely used.
Such a network typically comprises a plurality of intermediate routers interconnected at nodes of the network. These routers pass data in packets, between these nodes and ultimately between source and destination computing devices. Routing is typically effected using addresses in the packets identifying the source and destination of the packets. Individual routers obtain routing information to properly route packets from other routers at adjacent nodes of the network in order to establish a path across the network for any given packet.
In a typical packet-switched network, packets may be transmitted between source and destinations over multiple paths and at different speeds. Accordingly, packet propagation times are often not easy to predict. As well, packets are often lost or corrupted. Known protocols ensure reliable packet delivery, re-transmit lost packets and re-order received packets to ensure that received packets are processed in the order in which they were transmitted. Such reliable protocols, however, are ill suited to real time delivery of data across the network.
Certain network applications require data to be delivered in real time or near real time. Such applications may, for example, deliver, receive and process data representing streams of audio or video. Numerous protocols used to deliver continuous data streams are known. These protocols typically 91436-127 MZ/br do not ensure delivery of packets, and compensate for lost packets otherwise.
Other applications may require intermittent delivery of periodic bursts of data in real time. Such applications may include real time message notification applications. Example applications include telephone call, facsimile, electronic mail message, and financial event notification applications using the data network.
Delivery delay may be particularly acute for transmission of the first packet of infrequent bursts of data from a source to a destination. As understood by those skilled in the art, this delay or latency is primarily the result of intermediate routers within the network that do not retain routing information indefinitely. Thus, during infrequent contact, intermediate routers, often queue packets with unknown destination addresses and re-acquire routing information in order to establish a path to the destination. Routers may discard packets if they are unable to buffer them while routing information is acquired. As noted, routing information is acquired from adjacent routers, that in turn, acquire further routing information from other adjacent routers. Routers may also discard requests for routing information in the event they are unable to buffer such requests. These delays are particularly pronounced when the network is congested.
Accordingly, a protocol reducing transmission latency, suited for near real time delivery of data is desirable.
SUMMARY OF THE INVENTION:
In accordance with the present invention, there is provided a method of transmitting data from a first computing device to a second computing device over a packet switched network, the method comprising the steps of:
FIELD OF THE INVENTION:
The present invention relates to data network protocols, and more particularly to a low latency, packet based protocol.
BACKGROUND OF THE INVENTION:
Packet switched computer networks have become widely used.
Such a network typically comprises a plurality of intermediate routers interconnected at nodes of the network. These routers pass data in packets, between these nodes and ultimately between source and destination computing devices. Routing is typically effected using addresses in the packets identifying the source and destination of the packets. Individual routers obtain routing information to properly route packets from other routers at adjacent nodes of the network in order to establish a path across the network for any given packet.
In a typical packet-switched network, packets may be transmitted between source and destinations over multiple paths and at different speeds. Accordingly, packet propagation times are often not easy to predict. As well, packets are often lost or corrupted. Known protocols ensure reliable packet delivery, re-transmit lost packets and re-order received packets to ensure that received packets are processed in the order in which they were transmitted. Such reliable protocols, however, are ill suited to real time delivery of data across the network.
Certain network applications require data to be delivered in real time or near real time. Such applications may, for example, deliver, receive and process data representing streams of audio or video. Numerous protocols used to deliver continuous data streams are known. These protocols typically 91436-127 MZ/br do not ensure delivery of packets, and compensate for lost packets otherwise.
Other applications may require intermittent delivery of periodic bursts of data in real time. Such applications may include real time message notification applications. Example applications include telephone call, facsimile, electronic mail message, and financial event notification applications using the data network.
Delivery delay may be particularly acute for transmission of the first packet of infrequent bursts of data from a source to a destination. As understood by those skilled in the art, this delay or latency is primarily the result of intermediate routers within the network that do not retain routing information indefinitely. Thus, during infrequent contact, intermediate routers, often queue packets with unknown destination addresses and re-acquire routing information in order to establish a path to the destination. Routers may discard packets if they are unable to buffer them while routing information is acquired. As noted, routing information is acquired from adjacent routers, that in turn, acquire further routing information from other adjacent routers. Routers may also discard requests for routing information in the event they are unable to buffer such requests. These delays are particularly pronounced when the network is congested.
Accordingly, a protocol reducing transmission latency, suited for near real time delivery of data is desirable.
SUMMARY OF THE INVENTION:
In accordance with the present invention, there is provided a method of transmitting data from a first computing device to a second computing device over a packet switched network, the method comprising the steps of:
91436-127 MZ/br a. forming a first protocol data unit ("PDU") comprising the data at the first computing device;
b. forming at least one subsequent PDUs, comprising the data at the first computing device;
c. transmitting a set of PDUs comprising the first and subsequent PDUs from the first computing device to the second computing device using the network; and d. while receipt of the first PDU formed in step a. has not been acknowledged to the first computing device by the second computing device, re-transmitting the first PDU from the first computing device to the second computing device.
In accordance with another aspect of the invention, there is provided a method of receiving data within a protocol data unit ("PDU") at a second computer comprising the steps of:
a. establishing a data exchange session with a first computer;
b. receiving from the first computer, a plurality of packets, each of the packets comprising a PDU in a set of PDUs, each of the PDUs comprising the data and an identical PDU sequence number, only some of the packets further comprising a packet sequence number; and c. processing one of the PDUs received in step b. and discarding the remaining PDUs received in step b.
In accordance with a further aspect, there is provided a method of exchanging data between a second computing device and a first computing device during a data exchange session, the method comprising the steps of:
a. transferring an indicator of a session commencement from the second computing device to the second first computing device;
b. transferring from one of the first and second computing devices to the other of the first and second computing devices indicators of first and second logical ports to be used during the session;
b. forming at least one subsequent PDUs, comprising the data at the first computing device;
c. transmitting a set of PDUs comprising the first and subsequent PDUs from the first computing device to the second computing device using the network; and d. while receipt of the first PDU formed in step a. has not been acknowledged to the first computing device by the second computing device, re-transmitting the first PDU from the first computing device to the second computing device.
In accordance with another aspect of the invention, there is provided a method of receiving data within a protocol data unit ("PDU") at a second computer comprising the steps of:
a. establishing a data exchange session with a first computer;
b. receiving from the first computer, a plurality of packets, each of the packets comprising a PDU in a set of PDUs, each of the PDUs comprising the data and an identical PDU sequence number, only some of the packets further comprising a packet sequence number; and c. processing one of the PDUs received in step b. and discarding the remaining PDUs received in step b.
In accordance with a further aspect, there is provided a method of exchanging data between a second computing device and a first computing device during a data exchange session, the method comprising the steps of:
a. transferring an indicator of a session commencement from the second computing device to the second first computing device;
b. transferring from one of the first and second computing devices to the other of the first and second computing devices indicators of first and second logical ports to be used during the session;
91436-127 MZ/br c. transferring a PDU comprising the data from the first computing device to the second computing device using the first logical port; and d. transferring a PDU comprising the data from the first computing device to the second computing device using the second logical port.
According to a yet further aspect of the invention, there is provided a computer readable medium comprising a software program that when loaded into memory of a computer comprising a network interface, adapts the computer to:
a. form a first protocol data unit ("PDU") comprising data;
b. form at least one subsequent PDUs, comprising data identical to data of the first PDU;
c. transmit a set of PDUs comprising the first and subsequent PDUs from the computer to a second computing device using the network interface; and d. while receipt of the first PDU has ,not been acknowledged to the computer by the second computing device, re-transmitting the first PDU to said second computing device.
According to a yet further aspect of the invention, there is provided a method of operating first and second computing devices interconnected by a packet switched data network, during a data exchange session, the method comprising the steps of a. establishing the data exchange session between the second computing device and the first computing device;
b. transmitting a set of at least two PDUs in packets from the first computing device to the second computing device, each PDU in the set of PDUs comprising identical data and an identical PDU
sequence number, at least one packet further comprising a packet sequence number;
According to a yet further aspect of the invention, there is provided a computer readable medium comprising a software program that when loaded into memory of a computer comprising a network interface, adapts the computer to:
a. form a first protocol data unit ("PDU") comprising data;
b. form at least one subsequent PDUs, comprising data identical to data of the first PDU;
c. transmit a set of PDUs comprising the first and subsequent PDUs from the computer to a second computing device using the network interface; and d. while receipt of the first PDU has ,not been acknowledged to the computer by the second computing device, re-transmitting the first PDU to said second computing device.
According to a yet further aspect of the invention, there is provided a method of operating first and second computing devices interconnected by a packet switched data network, during a data exchange session, the method comprising the steps of a. establishing the data exchange session between the second computing device and the first computing device;
b. transmitting a set of at least two PDUs in packets from the first computing device to the second computing device, each PDU in the set of PDUs comprising identical data and an identical PDU
sequence number, at least one packet further comprising a packet sequence number;
91436-127 MZ/br c. processing one PDU in the set at the second computing device;
d. acknowledging receipt of packets that comprise packet sequence numbers, to the first computing device.
According to a yet further aspect of the invention, there is provided a computer comprising:
a. a processor;
b. a network interface in communication with the processor, for connection with a data network;
c. persistent memory in communication with the processor, the memory comprising software adapting the computer to:
i. form a first protocol data unit (PDU) comprising data;
ii. form at least one subsequent PDUs, comprising the data;
iii. transmit a set PDUs comprising the first and subsequent PDUs to a second computing device using the network interface; and iv. while receipt of the first PDU has not been acknowledged to the computer, by the second computing device, re-transmit the first PDU
from the first computing device to said second computing device.
According to a yet further aspect of the invention, there is provided a computer comprising:
a. a processor;
b. a network interface in communication with the processor, for connection with a data network;
c. memory in communication with the processor, the memory comprising software adapting the computer to:
a. establish a data exchange session with a second computer;
b. receive from the second computer, a plurality of packets, each of the packets comprising a 91436-127 MZ/br PDU in a set of PDUs, each of the PDUs comprising the data and an identical PDU
sequence number, only some of the packets further comprising a packet sequence number;
and c. process one of the PDUs received in step b. and discard the remaining PDUs received in step b.
According to a yet further aspect, there is provided a computing device interconnected with a network, the device comprising:
i. means for forming a first protocol data unit (PDU) comprising data;
ii. means for forming at least one subsequent PDUs, comprising the data;
iii. means for transmitting a set of PDUs comprising the first and subsequent PDUs to a second computing device using the network interface; and iv. means for re-transmitting the first PDU to the second computing device, while receipt of the first PDU has not been acknowledged to the computing device, by said second computing device.
BRIEF DESCRIPTION OF THE DRAWING:
In figures, which illustrate preferred embodiments of the invention, FIG. 1 illustrates two network interconnected computing devices, exemplary of embodiments of the present invention;
FIG. 2 schematically illustrates an architecture of one of the devices of FIG. 1;
FIG. 3 illustrates an organization of memory of one of the devices of FIG. 1;
d. acknowledging receipt of packets that comprise packet sequence numbers, to the first computing device.
According to a yet further aspect of the invention, there is provided a computer comprising:
a. a processor;
b. a network interface in communication with the processor, for connection with a data network;
c. persistent memory in communication with the processor, the memory comprising software adapting the computer to:
i. form a first protocol data unit (PDU) comprising data;
ii. form at least one subsequent PDUs, comprising the data;
iii. transmit a set PDUs comprising the first and subsequent PDUs to a second computing device using the network interface; and iv. while receipt of the first PDU has not been acknowledged to the computer, by the second computing device, re-transmit the first PDU
from the first computing device to said second computing device.
According to a yet further aspect of the invention, there is provided a computer comprising:
a. a processor;
b. a network interface in communication with the processor, for connection with a data network;
c. memory in communication with the processor, the memory comprising software adapting the computer to:
a. establish a data exchange session with a second computer;
b. receive from the second computer, a plurality of packets, each of the packets comprising a 91436-127 MZ/br PDU in a set of PDUs, each of the PDUs comprising the data and an identical PDU
sequence number, only some of the packets further comprising a packet sequence number;
and c. process one of the PDUs received in step b. and discard the remaining PDUs received in step b.
According to a yet further aspect, there is provided a computing device interconnected with a network, the device comprising:
i. means for forming a first protocol data unit (PDU) comprising data;
ii. means for forming at least one subsequent PDUs, comprising the data;
iii. means for transmitting a set of PDUs comprising the first and subsequent PDUs to a second computing device using the network interface; and iv. means for re-transmitting the first PDU to the second computing device, while receipt of the first PDU has not been acknowledged to the computing device, by said second computing device.
BRIEF DESCRIPTION OF THE DRAWING:
In figures, which illustrate preferred embodiments of the invention, FIG. 1 illustrates two network interconnected computing devices, exemplary of embodiments of the present invention;
FIG. 2 schematically illustrates an architecture of one of the devices of FIG. 1;
FIG. 3 illustrates an organization of memory of one of the devices of FIG. 1;
91436-127 MZ/br FIGS. 4A illustrate a protocol data unit exemplary of an embodiment of the present invention;
FIG. 4B illustrates a protocol session status block maintained by the devices of FIG. 1;
FIGS. 5A, 5B and 6 are flowcharts of methods exemplary of embodiments of the present invention; and FIG. 7 illustrates the exchange of data between computing devices using methods exemplary of the present invention.
DETAILED DESCRIPTION:
FIG. 1 illustrates first and second computing devices l0a and lOb (collectively 10), exemplary of computing devices embodying the present invention. As illustrated, first and second computing devices l0a and lOb are interconnected by data network 12.
In the illustrated embodiment, network 12 is a packet switched communications network that preferably allows interconnected computing devices to exchange data using known packet based protocols, such as the Internet protocol ("IP"), as detailed in RFC 791. Network 12 comprises a plurality of switches or routers, at nodes of the network, in communication with each other and adapted to pass packets between these nodes.
Three such routers 14a, 14b and 14c are illustrated. Other network routers, switches and equipment, also forming part of network 12, are not illustrated. Network 12 may be a conventional local or wide area network, an intranet, the public Internet, a cellular network, another wireless network, or the like.
A preferred architecture of each of devices 10 is schematically illustrated in FIG 2. In the illustrated embodiments, first and second computing devices l0a and lOb are substantially similar. Each of devices 10 is typically a conventional network capable workstation. Each of devices 10 could, for example, be an Intel x86 based computers acting as a Windows NT server, client or the like.
Each of devices 10 comprises a processor 16, in communication with persistent storage memory 18, and network interface 20. As well, each of devices 10 may comprise a display 26 and input device 22, such as a keyboard, mouse or the like. Processor 16 is typically a conventional central processing unit, and may for example comprise a microprocessor in the INTEL x86 family. Of course, processor 16 could be a RISC based CPU; a Motorola CPU; or any other suitable processor known to those skilled in the art. Persistent storage memory 18 comprises a suitable combination of random access memory, read-only-memory, and disk storage memory used by processor 16 to store and execute software programs adapting devices 10 to exchange messages using network 12, in accordance with the present invention. Persistent storage memory 18 may include a device capable of reading and writing data to or from a computer readable medium 24 used to store software and data to be loaded into the remainder of memory 18. Computer readable medium 24 may be a CD-ROM, diskette, tape, ROM-Cartridge or the like. Network interface 20 comprises any interface suitable to physically link each of devices 10 to network 12. Interface 20, may for example be an Ethernet, ATM, ISDN interface or modem that may be used to pass data from and to the network 12.
While devices 10 have been illustrated as end-user computing devices, devices 10 could be any suitable devices forming nodes on network 12, including end-user equipment, servers, or network intermediaries.
An exemplary organization of persistent storage memory 18 of devices 10 is illustrated in FIG. 3. Stored within memory 18 are computer software programs and data that are loaded into working memory of each of devices 10 to permit these to be operable as network communication capable devices. As illustrated, memory 18 preferably stores operating system 91436-127 MZ/br software 34; application software 32; and data 30. Operating system software 34 may, for example, be Microsoft Windows NTTM
Workstation operating system software, Microsoft WindowsTM 3.1, 95, 98 or CE software, AppleTM MacintoshTM System 7.5 software, UNIXTM operating system software, or the like. Application software 32 includes network interface software 40, which typically includes an Internet protocol suite 42 allowing communication of devices 10 and thus operating system 34 with network 10, through physical network interface 20 (FIG. 2).
Application software 32 further comprises a communications application 38, capable of communicating with another of the network interconnected computing devices 10 over network 12, in a manner exemplary of a preferred embodiment of the present invention. Other applications 36 and data 30 used by an end-user at device 10 may also be stored within memory 18.
As understood by those skilled in the art, Internet protocol suite 42 supports the basic Internet protocol as detailed in RFC 791. Suite 42 enables devices 10 to exchange packets over network 12 using known IP protocols, including packets conforming to the transmission control protocol ("TCP/IP"), as detailed in RFC793, and the user datagram protocol ("UDP/IP") as detailed in RFC 768. Suitable Internet protocol suites, such as for example the Winsock suite, are available for various platforms. Alternatively, an Internet protocol suite may form part of operating system 34.
As further understood by those skilled in the art, UDP/IP
is often referred to as an unreliable, connectionless Internet protocol, while TCP/IP is often referred to as a reliable Internet protocol. TCP/IP ensures delivery of sent packets in order, while UDP/IP does not ensure delivery of packets, nor proper ordering of the packets.
FIG. 4B illustrates a protocol session status block maintained by the devices of FIG. 1;
FIGS. 5A, 5B and 6 are flowcharts of methods exemplary of embodiments of the present invention; and FIG. 7 illustrates the exchange of data between computing devices using methods exemplary of the present invention.
DETAILED DESCRIPTION:
FIG. 1 illustrates first and second computing devices l0a and lOb (collectively 10), exemplary of computing devices embodying the present invention. As illustrated, first and second computing devices l0a and lOb are interconnected by data network 12.
In the illustrated embodiment, network 12 is a packet switched communications network that preferably allows interconnected computing devices to exchange data using known packet based protocols, such as the Internet protocol ("IP"), as detailed in RFC 791. Network 12 comprises a plurality of switches or routers, at nodes of the network, in communication with each other and adapted to pass packets between these nodes.
Three such routers 14a, 14b and 14c are illustrated. Other network routers, switches and equipment, also forming part of network 12, are not illustrated. Network 12 may be a conventional local or wide area network, an intranet, the public Internet, a cellular network, another wireless network, or the like.
A preferred architecture of each of devices 10 is schematically illustrated in FIG 2. In the illustrated embodiments, first and second computing devices l0a and lOb are substantially similar. Each of devices 10 is typically a conventional network capable workstation. Each of devices 10 could, for example, be an Intel x86 based computers acting as a Windows NT server, client or the like.
Each of devices 10 comprises a processor 16, in communication with persistent storage memory 18, and network interface 20. As well, each of devices 10 may comprise a display 26 and input device 22, such as a keyboard, mouse or the like. Processor 16 is typically a conventional central processing unit, and may for example comprise a microprocessor in the INTEL x86 family. Of course, processor 16 could be a RISC based CPU; a Motorola CPU; or any other suitable processor known to those skilled in the art. Persistent storage memory 18 comprises a suitable combination of random access memory, read-only-memory, and disk storage memory used by processor 16 to store and execute software programs adapting devices 10 to exchange messages using network 12, in accordance with the present invention. Persistent storage memory 18 may include a device capable of reading and writing data to or from a computer readable medium 24 used to store software and data to be loaded into the remainder of memory 18. Computer readable medium 24 may be a CD-ROM, diskette, tape, ROM-Cartridge or the like. Network interface 20 comprises any interface suitable to physically link each of devices 10 to network 12. Interface 20, may for example be an Ethernet, ATM, ISDN interface or modem that may be used to pass data from and to the network 12.
While devices 10 have been illustrated as end-user computing devices, devices 10 could be any suitable devices forming nodes on network 12, including end-user equipment, servers, or network intermediaries.
An exemplary organization of persistent storage memory 18 of devices 10 is illustrated in FIG. 3. Stored within memory 18 are computer software programs and data that are loaded into working memory of each of devices 10 to permit these to be operable as network communication capable devices. As illustrated, memory 18 preferably stores operating system 91436-127 MZ/br software 34; application software 32; and data 30. Operating system software 34 may, for example, be Microsoft Windows NTTM
Workstation operating system software, Microsoft WindowsTM 3.1, 95, 98 or CE software, AppleTM MacintoshTM System 7.5 software, UNIXTM operating system software, or the like. Application software 32 includes network interface software 40, which typically includes an Internet protocol suite 42 allowing communication of devices 10 and thus operating system 34 with network 10, through physical network interface 20 (FIG. 2).
Application software 32 further comprises a communications application 38, capable of communicating with another of the network interconnected computing devices 10 over network 12, in a manner exemplary of a preferred embodiment of the present invention. Other applications 36 and data 30 used by an end-user at device 10 may also be stored within memory 18.
As understood by those skilled in the art, Internet protocol suite 42 supports the basic Internet protocol as detailed in RFC 791. Suite 42 enables devices 10 to exchange packets over network 12 using known IP protocols, including packets conforming to the transmission control protocol ("TCP/IP"), as detailed in RFC793, and the user datagram protocol ("UDP/IP") as detailed in RFC 768. Suitable Internet protocol suites, such as for example the Winsock suite, are available for various platforms. Alternatively, an Internet protocol suite may form part of operating system 34.
As further understood by those skilled in the art, UDP/IP
is often referred to as an unreliable, connectionless Internet protocol, while TCP/IP is often referred to as a reliable Internet protocol. TCP/IP ensures delivery of sent packets in order, while UDP/IP does not ensure delivery of packets, nor proper ordering of the packets.
TCP/IP is a connection oriented protocol. TCP/IP
compliant packets include sequence numbers indicating a relative order of packets sent from a sender to a recipient during the connection. As well, each TCP/IP packet may further contain an acknowledgment sequence number which is piggybacked on sent packets to acknowledge previously received packets. The use of TCP/IP between a sender and recipient ensures that lost packets are re-transmitted; that received packets are properly ordered; and that duplicate packets are discarded. TCP/IP, however, does not ensure real time communications between a sender and recipient. As understood by a person skilled in the art, implementations of TCP/IP
typically require lost packets to be re-transmitted at exponentially increasing re-transmission intervals. The intervals are usually dependent upon the measured round-trip time for several packets. By convention, each subsequent interval is double the previous interval. This is largely because packets are often lost, and therefore re-transmitted, as a result of network congestion. By increasing the re-transmission intervals, TCP/IP re-transmission is less likely to contribute to network congestion. For example, for a round-trip delay of ls, TCP/IP packets are re-transmitted at intervals of 2s; 4s; 8s; 16s; (ie. a packet is re-transmitted 2s, 6s, 14s and 32s after the initial packet) and so on.
UDP/IP, on the other hand is a connectionless protocol.
UDP/IP packets are simply transmitted from a sender to a recipient without any mechanism that ensures their correct, or ordered receipt. UDP/IP packets thus do not contain sequence numbers, and are not re-transmitted.
Communications application 38 within memory 18 enables processor 16 to use the Internet protocol suite 42 , and the supported TCP/IP and UDP/IP protocols to transmit protocol data units ("PDU"s) having the format illustrated in FIG. 4A, and exemplary of an embodiment of the present invention. As illustrated, an exemplary PDU 50 comprises a PDU header 51, and a PDU body 58 containing data. PDU header 51 comprises version 91436-127 MZ/br number, sequence number and re-transmission count fields 52, 54 and 56. As will become apparent, PDUs 50 are preferably encapsulated in TCP/IP and UDP/IP compliant packets and transmitted at determined intervals from a sender to a recipient. In an example embodiment, the length of a PDU may be fixed at 4096 bytes. However, a person skilled in the art will appreciate that the length could be varied from PDU to PDU. PDU header 51 could accordingly optionally include a field indicating the PDU's length. Alternatively, the length of each PDU could be based on, and indicated by, the protocol used to encapsulate the PDU.
In operation, first and second computing devices l0a and lOb illustrated in FIG. 1 wish to exchange data over network 10 using an exemplary enhanced protocol. Steps 500 performed by first computing device l0a are illustrated in FIGS. 5A and 5B, while steps 600 performed by second computing device lOb are illustrated in FIG. 6. Specifically, second computing device lOb first establishes an enhanced protocol session with first computing device 10a in steps S502 and 5602 by first establishing a TCP/IP connection with first computing device l0a over a well known logical TCP/IP port of first computing device 10a. The network address of first computing device l0a may, for example, be obtained by second computing device lOb using the known domain name service, as detailed in RFC 2136 and 2137 or by any other suitable method. In the preferred embodiment, packets destined for the "well known" TCP/IP port 5555 of device l0a are used to identify TCP/IP packets forming part of an enhanced protocol session. Of course, another port could be designated as a well known port for the enhanced protocol.
The TCP/IP port of second computing device lOb used to establish the connection is selected by communications application 38 (FIG. 3) at second computing device lOb. Once a TCP/IP connection is established, second computing device lOb provides an initial control block (not shown) to first computing device l0a over network 12. This control block is 91436-127 MZ/br used to establish an enhanced protocol session between first computing device l0a and second computing device lOb using the enhanced protocol, exemplary of the present invention. This control block typically includes an identifier of second computing device lOb, which includes the IP address of second computing device lOb, and possibly another identifier such as an assigned numerical identifier known to both device l0a and lOb. Further the control block comprises an identifier of an available UDP/IP port at device lOb, selected by second device lOb. As will become apparent, a well known UDP/IP port at first device l0a will be used to transmit packets to the selected UDP/IP port at second device lOb.
Device l0a may acknowledge establishment of an enhanced session by providing an acknowledgment message to the TCP/IP
port of device lOb used to establish the enhanced protocol session.
Once an enhanced protocol session is established, communications application 38 at both devices 10 maintain an enhanced session status data block 60, as illustrated in FIG.
4B. Block 60 includes field 62 containing the IP address of the recipient device (for device l0a the IP address of device lOb is stored in field 62; for device lOb, the IP address of device l0a is stored in field 62); fields 64 and 66 comprising identifiers of the TCP/IP and UDP/IP ports of the recipient device that will be used to pass packets using the enhanced protocol; and field 68 containing the sequence number ("SEND SEQUENCE NO") of the currently transmitted PDU, and a field 70 containing the receive sequence number ("RECEIVE SEQUENCE NO") of the next expected PDU.
As will become apparent, the TCP/IP connection between TCP/IP port 5555 of device l0a and the selected port of device lOb is used to transmit TCP/IP compliant packets during an enhanced protocol session. Similarly, the well known UDP/IP
port 5555 is used to transmit packets from first device 10a;
the UDP/IP port corresponding to the UDP/IP port selected by 91436-127 MZ/br device lOb is used to receive these packets from first device 10a. Similarly, the UDP/IP port of devices 10a and lOb are stored in field 66 at devices lOb and l0a respectively. The TCP/IP port of devices 10a, and 10b are stored in field 64 at devices lOb and 10a, respectively. As well, an initial sequence number having a value of zero "0" is used for PDUs exchanged during the enhanced session, for traffic in either direction between devices l0a and lOb. This sequence number is initially stored in field 68 at device 10a, and field 70 of device lOb.
As should be apparent, communication during an enhanced protocol session may be bi-directional with data originating with both first and second computing devices 10a and lOb.
Similarly, either of first and second devices l0a or lOb could establish an enhanced session, provided that the IP address of a recipient device is available. For clarity, only data exchange from device l0a to device lOb is illustrated. Thus, in the described example, field 70 at device 10a, is not used.
Similarly, field 68 at device lOb is not used.
Once the initial control block has been exchanged, first computing device l0a manipulates data to be transferred in PDUs to second computing device lOb using the enhanced protocol.
Preferably, PDUs are transmitted in sets of four, with each set comprising an initial PDU and three subsequent PDUs all containing identical data, but a unique "re-transmission"
count in its re-transmission count field 56. A counter variable "i" preferably counts the number of sets of PDUs transmitted during a particular session, and is initialized with a value of zero in step 5504.
For each set of PDUs to be transmitted, a re-transmission counter "j" is initialized to have a value zero in step 5506.
An initial PDU of the form of PDU 50 (FIG. 4A) is formed in step 5508-5510. This initial PDU is formed using a first data portion, ("DPO") and appending an appropriate PDU header having 91436-127 MZ/br the form of header 51 (FIG. 4A) in steps 5510 and 5512. Header 51 of this PDU contains an initial PDU sequence number, as established in steps 5502 and 5602, ("SEND-SEQUENCE NO") that counts the sets of PDUs transmitted during a session, in its sequence number field 54, and a re-transmission count of j="0"
in re-transmission count field 56. Optionally, header 51 may further contain a version number of communications application 38 at device l0a in field 52 that may later be used by second computing device 10b to verify that the PDU was formed by a compatible version of communications application 38. In step S514, this initial PDU is passed to IP protocol stack 42 of network software 40, by communications application 38 where it is encapsulated in a TCP/IP compliant packet, and dispatched to the network address of second computing device 10a using the port identified in field 64 (FIG. 4B) in steps 5502 and 5602 over network 12 and using the known TCP/IP protocol.
As will be appreciated, the IP protocol stack will associate with the TCP/IP packet containing the PDU, an additional TCP/IP sequence number used by the TCP/IP protocol to ensure delivery of the TCP/IP packet to the second computing device. Eventually, once the TCP/IP packet, is safely received, it will be acknowledged by second computing device lOb, indicated by an appropriate TCP/IP acknowledgment sequence number in another TCP/IP packet originating with second computing device lOb, destined for first computing device 10a.
If the TCP/IP packet containing the PDU is not acknowledged by second computing device lOb in a specified interval, it is re-transmitted. If the packet containing the initial PDU is still not acknowledged within a second specified interval, Internet suite 42 causes first computing device l0a to re-transmit the packet a second time. Likewise, if receipt of the packet is not acknowledged in third or subsequent intervals, the packet is again re-transmitted by the first computing device 10a. As noted, the re-transmission intervals increase with each re-transmission of the packet. Thus, eventual receipt of the packet may take some time. If the 91436-127 MZ/br TCP/IP packet is not acknowledged after numerous re-transmissions, first computing device,l0a times out and network interface software 40 generates an appropriate error, that communicated to communications application 38.
In order to reduce such delays, caused largely by re-transmission of packets in accordance with the known TCP/IP
protocol, communications application 38, dispatches the above described initial PDU and a plurality of subsequent PDUs having the format of PDU 50 (FIG.4) and containing identical data portions in field 58, and sequence numbers in field 54.
Each data portion and sequence number are identical to those of the initial PDU described above. The subsequent PDUs, however, comprise re-transmission counts of j="1", "2", "3", and so on, in field 56 of header 51. As illustrated, the subsequent PDUs are formed and transmitted in steps 5516-5522.
The subsequent PDUs are transmitted by first computing device l0a under control of communications application 38, through network interface software 40 and network interface 20 (FIG.
2) using the known UDP/IP protocol and the established UDP/IP
ports stored in field 66 at devices l0a and lOb in steps 5502 and 5602.
In the preferred embodiment exactly three subsequent PDUs are formed for each unique data portion, but fewer or more could easily be formed.
Subsequent PDUs are transmitted to second computing device lOb in step 5520 preferably at regular intervals of 500ms, and preferably commencing within 500ms after transmission of the initial PDU. It worth noting that these intervals are typically less than the typical re-transmission intervals of the TCP/IP packets. Of course, other intervals such as intervals between 200 and 1200ms could be chosen. These intervals may be timed by communications application 38 in any conventional manner.
91436-127 MZ/br As noted, each PDU preferably comprises 4096 bytes (including header and data). Accordingly, once the third PDU
in a set has been transmitted, counter "i" and SEND SEQUENCE NO
variables are incremented in step 5524, and steps 5506 to 5522 are repeated, for a new set PDUs and additional data. That is, four PDUs having an identical sequence number are transmitted for each block of data, until all data to be transmitted has been so transmitted.
Once all data has been transmitted, first computing device l0a may terminate the enhanced session in step 5528.
The session may be terminated, simply by terminating the TCP/IP
connection established between first and second computing devices l0a and lOb during establishment of the enhanced protocol session.
As will be appreciated, in steps 500 of the exemplary method, sets of PDUs are transmitted sequentially from device l0a to device lOb. That is all PDUs in a first set are transmitted before PDUs in a second set are transmitted.
However, the first PDU of a subsequent set could easily be transmitted after a TCP/IP compliant packet containing a PDU
for the previous set has been transmitted. Device l0a would accordingly execute several program threads, with each thread performing steps similar to steps 500, in accordance with known programming techniques.
Second computing device lOb, after establishing an enhanced session including a TCP/IP connection over the port specified in field 64, initially awaits receipt of the PDUs containing the sequence number (RECEIVE-SEQUENCE NO=0) as agreed upon in steps 5502 and 5602 and stored in its session status block 60. Upon receipt of any of the PDUs in step 5606, second computing device lOb extracts the PDU from the TCP/IP
or UDP/IP packet in step 5608. Optionally, second computing device lOb compares the version number associated with the PDU
in field 52 to determine if the PDU was formed by a device executing an application compatible with communications 91436-127 MZ/br application 38 of second computing device lOb in step 5610.
If not, communications application 38 causes second computing device lOb to generate a suitable error in step 5614.
Thereafter enhanced session is ended by terminating the TCP/IP
connection between devices l0a and 10b.
If the version number is appropriate, communications application 38, causes second computing device lOb to examine the PDU sequence number as contained in field 54 of header 51 to determine whether it equals the expected receive sequence number ("RECEIVE SEQUENCE NO") maintained in field 70 of block 60 at device lOb, in step 5614. If not, the PDU is discarded in step 5616. Typically, a non-expected sequence number indicates that the received PDU has been previously received, either by way of a TCP/IP packet or an UDP/IP packet. If the received sequence number equals the expected sequence number, then one of the four PDUs has been received and the PDU is processed in step 5616. The sequence number RECEIVE SEQUENCE NO in field 70 of block 60 is incremented in step S618 at device 10a, thus configuring second computing device lOb to now expect a PDU, from the next set of PDUs. Now step 5606 and those subsequent to S606 are repeated.
For each transmitted set of PDUs, the initial TCP/IP
compliant packet containing the PDU for that set will eventually be received and acknowledged using the TCP/IP
protocol. The TCP/IP compliant packet may be received after numerous re-transmissions, some time after it is initially dispatched, and after one or more of the UDP/IP compliant packets containing in the set are received. As detailed, this is particularly acute when network 12 is congested.
An example packet flow diagram of PDUs using the described enhanced protocol, between first computing device l0a and second computing device lOb, by way of a router 14a (FIG. 1) is illustrated in FIG. 7. The illustrated flow diagram assumes that an enhanced communications session for using the described protocol has already been established and that TCP/IP and UDP/IP ports have been negotiated between first and second 91436-127 MZ/br computing devices l0a and lOb, in accordance with steps 5502 and 5602.
As shown, an initial PDU in a first set of PDUs having the format of PDU 50 and containing a re-transmission count field of "0" and a data portion DPO in field 58 is encapsulated in a TCP/IP packet is dispatched by first computing device 10a at time t=Os. At time t=500ms a first subsequent PDU in the first set, also having the format of PDU 50, but having a re-transmission count of "1" in field 56 and containing the same data portion DPO in field 58 is encapsulated in a UDP/IP packet and dispatched. Third and fourth subsequent PDUs in the set, with unique re-transmission counts containing identical data portions DPO are encapsulated in UDP/IP packets and dispatched at t=1000ms and t=1500ms, respectively. At about t=100 ms, the first PDU encapsulated in a TCP/IP compliant packet arrives at the illustrated router 14a, and is lost . In the illustrated example, the first and third subsequent PDUs arrive at second computing device lOb, at about 750ms and 1750ms while the second subsequent PDU is lost at router 14a at about t=1100 ms.
The first subsequent PDU is processed by second computing device lOb, while the third subsequent PDU is discarded.
After transmission of four PDUs containing data portion DPO, a first PDU in a second set, having the format of PDU 50 and containing another data portion, DP1, in field 58 is transmitted in an encapsulated TCP/IP packet at t=1600.
Similar UDP/IP compliant packets in the second set containing DP1 are transmitted from first computing device l0a at 2100ms, 2600ms, and 3100ms.
The TCP/IP packet containing the initial PDU in the second set is received at t=1850 ms. Later, received UDP/IP packets containing subsequent PDU, in the second set may thus be discarded. Receipt of the TCP/IP packet containing DP1, however, cannot yet be acknowledged as the previous TCP/IP
packet containing DPO has not yet been received.
91436-127 MZ/br At t=2000 ms a TCP/IP packet containing the first PDU is re-transmitted by the TCP/IP portion of protocol stack 42 from first computing device 10a, because its receipt has not yet been acknowledged by second computing device lOb. This re-transmitted PDU arrives at router 14a at about t=2100 ms, and at second computing device lOb at 2150 ms. Shortly thereafter, at t=2200 ms, Internet protocol suite 42 of second computing device lOb acknowledges receipt of both TCP/IP packets containing DPO
and DP1.
As should be apparent, device lOb need not wait until an entire set of PDUs has been transmitted before transmitting the first PDU in a subsequent set. As such, several program threads containing steps similar to steps 500 could be concurrently in progress.
As noted, the above described methods and protocol are particularly well suited for delivery of messages that are infrequent. Accordingly, the methods and protocol are particularly well suited for delivery of notification messages used to advise an end-user at a second computing device computing device lOb of an incoming telephone call at that end-user's telephone line when the telephone is in use, as disclosed in Canadian Patent Application No. 2,263,264. PDU's could thus contain information representing an incoming call and could include information about a caller. These PDUs could be processed by communications application 38 or another application to display incoming call information to the end-user at second computing device computing device lOb. Of course, many applications of the invention would be apparent to those skilled in the art.
While the above described embodiment utilize the known TCP/IP and UDP/IP protocols, a person skilled in the art will appreciate that the embodiment could easily be modified to utilize other known protocols, such as the IPX and SPX
protocols, within the scope of this invention. Similarly, a reliable protocol similar to the TCP/IP protocol could easily be implemented by communications application 38, without reliance on TCP/IP.
Similarly, the described embodiments could be modified to buffer and re-order received UDP/IP packets containing the transmitted protocol. So modified, the enhanced protocol would ensure ordering of received PDUs without reliance on TCP/IP.
Similarly, the protocol could be enhanced to explicitly acknowledge receipt of PDUs, thereby reducing PDU re-transmissions in many instances. Similarly, the port numbers exchanged during the establishment of a session could be transmitted in the header of each PDU, thus eliminating the initial session control block, detailed above Similarly, while the organization of software blocks, and data portions have been illustrated as clearly delineated, a person skilled in the art will appreciate that the delineation between blocks and data portions is somewhat arbitrary.
Numerous other arrangements of software blocks and data are possible. Similarly, while second computing device 10b and first computing device l0a are substantially similar, a person skilled in the art will appreciate that second computing device lOb and first computing device l0a could be quite dissimilar.
Second computing device lOb could for example be adapted to perform only steps 600, while first computing device l0a could be adapted to perform only steps 500 (FIGS. 5A and 5B).
It will be understood that the invention is not limited to the illustrations described herein which are merely illustrative of preferred embodiments of carrying out the invention, and which are susceptible to modification of form, size, arrangement of parts, and details of operation. The invention, rather, is intended to encompass all such modification within its spirit and scope, as defined by the claims.
91436-127 MZ/br
compliant packets include sequence numbers indicating a relative order of packets sent from a sender to a recipient during the connection. As well, each TCP/IP packet may further contain an acknowledgment sequence number which is piggybacked on sent packets to acknowledge previously received packets. The use of TCP/IP between a sender and recipient ensures that lost packets are re-transmitted; that received packets are properly ordered; and that duplicate packets are discarded. TCP/IP, however, does not ensure real time communications between a sender and recipient. As understood by a person skilled in the art, implementations of TCP/IP
typically require lost packets to be re-transmitted at exponentially increasing re-transmission intervals. The intervals are usually dependent upon the measured round-trip time for several packets. By convention, each subsequent interval is double the previous interval. This is largely because packets are often lost, and therefore re-transmitted, as a result of network congestion. By increasing the re-transmission intervals, TCP/IP re-transmission is less likely to contribute to network congestion. For example, for a round-trip delay of ls, TCP/IP packets are re-transmitted at intervals of 2s; 4s; 8s; 16s; (ie. a packet is re-transmitted 2s, 6s, 14s and 32s after the initial packet) and so on.
UDP/IP, on the other hand is a connectionless protocol.
UDP/IP packets are simply transmitted from a sender to a recipient without any mechanism that ensures their correct, or ordered receipt. UDP/IP packets thus do not contain sequence numbers, and are not re-transmitted.
Communications application 38 within memory 18 enables processor 16 to use the Internet protocol suite 42 , and the supported TCP/IP and UDP/IP protocols to transmit protocol data units ("PDU"s) having the format illustrated in FIG. 4A, and exemplary of an embodiment of the present invention. As illustrated, an exemplary PDU 50 comprises a PDU header 51, and a PDU body 58 containing data. PDU header 51 comprises version 91436-127 MZ/br number, sequence number and re-transmission count fields 52, 54 and 56. As will become apparent, PDUs 50 are preferably encapsulated in TCP/IP and UDP/IP compliant packets and transmitted at determined intervals from a sender to a recipient. In an example embodiment, the length of a PDU may be fixed at 4096 bytes. However, a person skilled in the art will appreciate that the length could be varied from PDU to PDU. PDU header 51 could accordingly optionally include a field indicating the PDU's length. Alternatively, the length of each PDU could be based on, and indicated by, the protocol used to encapsulate the PDU.
In operation, first and second computing devices l0a and lOb illustrated in FIG. 1 wish to exchange data over network 10 using an exemplary enhanced protocol. Steps 500 performed by first computing device l0a are illustrated in FIGS. 5A and 5B, while steps 600 performed by second computing device lOb are illustrated in FIG. 6. Specifically, second computing device lOb first establishes an enhanced protocol session with first computing device 10a in steps S502 and 5602 by first establishing a TCP/IP connection with first computing device l0a over a well known logical TCP/IP port of first computing device 10a. The network address of first computing device l0a may, for example, be obtained by second computing device lOb using the known domain name service, as detailed in RFC 2136 and 2137 or by any other suitable method. In the preferred embodiment, packets destined for the "well known" TCP/IP port 5555 of device l0a are used to identify TCP/IP packets forming part of an enhanced protocol session. Of course, another port could be designated as a well known port for the enhanced protocol.
The TCP/IP port of second computing device lOb used to establish the connection is selected by communications application 38 (FIG. 3) at second computing device lOb. Once a TCP/IP connection is established, second computing device lOb provides an initial control block (not shown) to first computing device l0a over network 12. This control block is 91436-127 MZ/br used to establish an enhanced protocol session between first computing device l0a and second computing device lOb using the enhanced protocol, exemplary of the present invention. This control block typically includes an identifier of second computing device lOb, which includes the IP address of second computing device lOb, and possibly another identifier such as an assigned numerical identifier known to both device l0a and lOb. Further the control block comprises an identifier of an available UDP/IP port at device lOb, selected by second device lOb. As will become apparent, a well known UDP/IP port at first device l0a will be used to transmit packets to the selected UDP/IP port at second device lOb.
Device l0a may acknowledge establishment of an enhanced session by providing an acknowledgment message to the TCP/IP
port of device lOb used to establish the enhanced protocol session.
Once an enhanced protocol session is established, communications application 38 at both devices 10 maintain an enhanced session status data block 60, as illustrated in FIG.
4B. Block 60 includes field 62 containing the IP address of the recipient device (for device l0a the IP address of device lOb is stored in field 62; for device lOb, the IP address of device l0a is stored in field 62); fields 64 and 66 comprising identifiers of the TCP/IP and UDP/IP ports of the recipient device that will be used to pass packets using the enhanced protocol; and field 68 containing the sequence number ("SEND SEQUENCE NO") of the currently transmitted PDU, and a field 70 containing the receive sequence number ("RECEIVE SEQUENCE NO") of the next expected PDU.
As will become apparent, the TCP/IP connection between TCP/IP port 5555 of device l0a and the selected port of device lOb is used to transmit TCP/IP compliant packets during an enhanced protocol session. Similarly, the well known UDP/IP
port 5555 is used to transmit packets from first device 10a;
the UDP/IP port corresponding to the UDP/IP port selected by 91436-127 MZ/br device lOb is used to receive these packets from first device 10a. Similarly, the UDP/IP port of devices 10a and lOb are stored in field 66 at devices lOb and l0a respectively. The TCP/IP port of devices 10a, and 10b are stored in field 64 at devices lOb and 10a, respectively. As well, an initial sequence number having a value of zero "0" is used for PDUs exchanged during the enhanced session, for traffic in either direction between devices l0a and lOb. This sequence number is initially stored in field 68 at device 10a, and field 70 of device lOb.
As should be apparent, communication during an enhanced protocol session may be bi-directional with data originating with both first and second computing devices 10a and lOb.
Similarly, either of first and second devices l0a or lOb could establish an enhanced session, provided that the IP address of a recipient device is available. For clarity, only data exchange from device l0a to device lOb is illustrated. Thus, in the described example, field 70 at device 10a, is not used.
Similarly, field 68 at device lOb is not used.
Once the initial control block has been exchanged, first computing device l0a manipulates data to be transferred in PDUs to second computing device lOb using the enhanced protocol.
Preferably, PDUs are transmitted in sets of four, with each set comprising an initial PDU and three subsequent PDUs all containing identical data, but a unique "re-transmission"
count in its re-transmission count field 56. A counter variable "i" preferably counts the number of sets of PDUs transmitted during a particular session, and is initialized with a value of zero in step 5504.
For each set of PDUs to be transmitted, a re-transmission counter "j" is initialized to have a value zero in step 5506.
An initial PDU of the form of PDU 50 (FIG. 4A) is formed in step 5508-5510. This initial PDU is formed using a first data portion, ("DPO") and appending an appropriate PDU header having 91436-127 MZ/br the form of header 51 (FIG. 4A) in steps 5510 and 5512. Header 51 of this PDU contains an initial PDU sequence number, as established in steps 5502 and 5602, ("SEND-SEQUENCE NO") that counts the sets of PDUs transmitted during a session, in its sequence number field 54, and a re-transmission count of j="0"
in re-transmission count field 56. Optionally, header 51 may further contain a version number of communications application 38 at device l0a in field 52 that may later be used by second computing device 10b to verify that the PDU was formed by a compatible version of communications application 38. In step S514, this initial PDU is passed to IP protocol stack 42 of network software 40, by communications application 38 where it is encapsulated in a TCP/IP compliant packet, and dispatched to the network address of second computing device 10a using the port identified in field 64 (FIG. 4B) in steps 5502 and 5602 over network 12 and using the known TCP/IP protocol.
As will be appreciated, the IP protocol stack will associate with the TCP/IP packet containing the PDU, an additional TCP/IP sequence number used by the TCP/IP protocol to ensure delivery of the TCP/IP packet to the second computing device. Eventually, once the TCP/IP packet, is safely received, it will be acknowledged by second computing device lOb, indicated by an appropriate TCP/IP acknowledgment sequence number in another TCP/IP packet originating with second computing device lOb, destined for first computing device 10a.
If the TCP/IP packet containing the PDU is not acknowledged by second computing device lOb in a specified interval, it is re-transmitted. If the packet containing the initial PDU is still not acknowledged within a second specified interval, Internet suite 42 causes first computing device l0a to re-transmit the packet a second time. Likewise, if receipt of the packet is not acknowledged in third or subsequent intervals, the packet is again re-transmitted by the first computing device 10a. As noted, the re-transmission intervals increase with each re-transmission of the packet. Thus, eventual receipt of the packet may take some time. If the 91436-127 MZ/br TCP/IP packet is not acknowledged after numerous re-transmissions, first computing device,l0a times out and network interface software 40 generates an appropriate error, that communicated to communications application 38.
In order to reduce such delays, caused largely by re-transmission of packets in accordance with the known TCP/IP
protocol, communications application 38, dispatches the above described initial PDU and a plurality of subsequent PDUs having the format of PDU 50 (FIG.4) and containing identical data portions in field 58, and sequence numbers in field 54.
Each data portion and sequence number are identical to those of the initial PDU described above. The subsequent PDUs, however, comprise re-transmission counts of j="1", "2", "3", and so on, in field 56 of header 51. As illustrated, the subsequent PDUs are formed and transmitted in steps 5516-5522.
The subsequent PDUs are transmitted by first computing device l0a under control of communications application 38, through network interface software 40 and network interface 20 (FIG.
2) using the known UDP/IP protocol and the established UDP/IP
ports stored in field 66 at devices l0a and lOb in steps 5502 and 5602.
In the preferred embodiment exactly three subsequent PDUs are formed for each unique data portion, but fewer or more could easily be formed.
Subsequent PDUs are transmitted to second computing device lOb in step 5520 preferably at regular intervals of 500ms, and preferably commencing within 500ms after transmission of the initial PDU. It worth noting that these intervals are typically less than the typical re-transmission intervals of the TCP/IP packets. Of course, other intervals such as intervals between 200 and 1200ms could be chosen. These intervals may be timed by communications application 38 in any conventional manner.
91436-127 MZ/br As noted, each PDU preferably comprises 4096 bytes (including header and data). Accordingly, once the third PDU
in a set has been transmitted, counter "i" and SEND SEQUENCE NO
variables are incremented in step 5524, and steps 5506 to 5522 are repeated, for a new set PDUs and additional data. That is, four PDUs having an identical sequence number are transmitted for each block of data, until all data to be transmitted has been so transmitted.
Once all data has been transmitted, first computing device l0a may terminate the enhanced session in step 5528.
The session may be terminated, simply by terminating the TCP/IP
connection established between first and second computing devices l0a and lOb during establishment of the enhanced protocol session.
As will be appreciated, in steps 500 of the exemplary method, sets of PDUs are transmitted sequentially from device l0a to device lOb. That is all PDUs in a first set are transmitted before PDUs in a second set are transmitted.
However, the first PDU of a subsequent set could easily be transmitted after a TCP/IP compliant packet containing a PDU
for the previous set has been transmitted. Device l0a would accordingly execute several program threads, with each thread performing steps similar to steps 500, in accordance with known programming techniques.
Second computing device lOb, after establishing an enhanced session including a TCP/IP connection over the port specified in field 64, initially awaits receipt of the PDUs containing the sequence number (RECEIVE-SEQUENCE NO=0) as agreed upon in steps 5502 and 5602 and stored in its session status block 60. Upon receipt of any of the PDUs in step 5606, second computing device lOb extracts the PDU from the TCP/IP
or UDP/IP packet in step 5608. Optionally, second computing device lOb compares the version number associated with the PDU
in field 52 to determine if the PDU was formed by a device executing an application compatible with communications 91436-127 MZ/br application 38 of second computing device lOb in step 5610.
If not, communications application 38 causes second computing device lOb to generate a suitable error in step 5614.
Thereafter enhanced session is ended by terminating the TCP/IP
connection between devices l0a and 10b.
If the version number is appropriate, communications application 38, causes second computing device lOb to examine the PDU sequence number as contained in field 54 of header 51 to determine whether it equals the expected receive sequence number ("RECEIVE SEQUENCE NO") maintained in field 70 of block 60 at device lOb, in step 5614. If not, the PDU is discarded in step 5616. Typically, a non-expected sequence number indicates that the received PDU has been previously received, either by way of a TCP/IP packet or an UDP/IP packet. If the received sequence number equals the expected sequence number, then one of the four PDUs has been received and the PDU is processed in step 5616. The sequence number RECEIVE SEQUENCE NO in field 70 of block 60 is incremented in step S618 at device 10a, thus configuring second computing device lOb to now expect a PDU, from the next set of PDUs. Now step 5606 and those subsequent to S606 are repeated.
For each transmitted set of PDUs, the initial TCP/IP
compliant packet containing the PDU for that set will eventually be received and acknowledged using the TCP/IP
protocol. The TCP/IP compliant packet may be received after numerous re-transmissions, some time after it is initially dispatched, and after one or more of the UDP/IP compliant packets containing in the set are received. As detailed, this is particularly acute when network 12 is congested.
An example packet flow diagram of PDUs using the described enhanced protocol, between first computing device l0a and second computing device lOb, by way of a router 14a (FIG. 1) is illustrated in FIG. 7. The illustrated flow diagram assumes that an enhanced communications session for using the described protocol has already been established and that TCP/IP and UDP/IP ports have been negotiated between first and second 91436-127 MZ/br computing devices l0a and lOb, in accordance with steps 5502 and 5602.
As shown, an initial PDU in a first set of PDUs having the format of PDU 50 and containing a re-transmission count field of "0" and a data portion DPO in field 58 is encapsulated in a TCP/IP packet is dispatched by first computing device 10a at time t=Os. At time t=500ms a first subsequent PDU in the first set, also having the format of PDU 50, but having a re-transmission count of "1" in field 56 and containing the same data portion DPO in field 58 is encapsulated in a UDP/IP packet and dispatched. Third and fourth subsequent PDUs in the set, with unique re-transmission counts containing identical data portions DPO are encapsulated in UDP/IP packets and dispatched at t=1000ms and t=1500ms, respectively. At about t=100 ms, the first PDU encapsulated in a TCP/IP compliant packet arrives at the illustrated router 14a, and is lost . In the illustrated example, the first and third subsequent PDUs arrive at second computing device lOb, at about 750ms and 1750ms while the second subsequent PDU is lost at router 14a at about t=1100 ms.
The first subsequent PDU is processed by second computing device lOb, while the third subsequent PDU is discarded.
After transmission of four PDUs containing data portion DPO, a first PDU in a second set, having the format of PDU 50 and containing another data portion, DP1, in field 58 is transmitted in an encapsulated TCP/IP packet at t=1600.
Similar UDP/IP compliant packets in the second set containing DP1 are transmitted from first computing device l0a at 2100ms, 2600ms, and 3100ms.
The TCP/IP packet containing the initial PDU in the second set is received at t=1850 ms. Later, received UDP/IP packets containing subsequent PDU, in the second set may thus be discarded. Receipt of the TCP/IP packet containing DP1, however, cannot yet be acknowledged as the previous TCP/IP
packet containing DPO has not yet been received.
91436-127 MZ/br At t=2000 ms a TCP/IP packet containing the first PDU is re-transmitted by the TCP/IP portion of protocol stack 42 from first computing device 10a, because its receipt has not yet been acknowledged by second computing device lOb. This re-transmitted PDU arrives at router 14a at about t=2100 ms, and at second computing device lOb at 2150 ms. Shortly thereafter, at t=2200 ms, Internet protocol suite 42 of second computing device lOb acknowledges receipt of both TCP/IP packets containing DPO
and DP1.
As should be apparent, device lOb need not wait until an entire set of PDUs has been transmitted before transmitting the first PDU in a subsequent set. As such, several program threads containing steps similar to steps 500 could be concurrently in progress.
As noted, the above described methods and protocol are particularly well suited for delivery of messages that are infrequent. Accordingly, the methods and protocol are particularly well suited for delivery of notification messages used to advise an end-user at a second computing device computing device lOb of an incoming telephone call at that end-user's telephone line when the telephone is in use, as disclosed in Canadian Patent Application No. 2,263,264. PDU's could thus contain information representing an incoming call and could include information about a caller. These PDUs could be processed by communications application 38 or another application to display incoming call information to the end-user at second computing device computing device lOb. Of course, many applications of the invention would be apparent to those skilled in the art.
While the above described embodiment utilize the known TCP/IP and UDP/IP protocols, a person skilled in the art will appreciate that the embodiment could easily be modified to utilize other known protocols, such as the IPX and SPX
protocols, within the scope of this invention. Similarly, a reliable protocol similar to the TCP/IP protocol could easily be implemented by communications application 38, without reliance on TCP/IP.
Similarly, the described embodiments could be modified to buffer and re-order received UDP/IP packets containing the transmitted protocol. So modified, the enhanced protocol would ensure ordering of received PDUs without reliance on TCP/IP.
Similarly, the protocol could be enhanced to explicitly acknowledge receipt of PDUs, thereby reducing PDU re-transmissions in many instances. Similarly, the port numbers exchanged during the establishment of a session could be transmitted in the header of each PDU, thus eliminating the initial session control block, detailed above Similarly, while the organization of software blocks, and data portions have been illustrated as clearly delineated, a person skilled in the art will appreciate that the delineation between blocks and data portions is somewhat arbitrary.
Numerous other arrangements of software blocks and data are possible. Similarly, while second computing device 10b and first computing device l0a are substantially similar, a person skilled in the art will appreciate that second computing device lOb and first computing device l0a could be quite dissimilar.
Second computing device lOb could for example be adapted to perform only steps 600, while first computing device l0a could be adapted to perform only steps 500 (FIGS. 5A and 5B).
It will be understood that the invention is not limited to the illustrations described herein which are merely illustrative of preferred embodiments of carrying out the invention, and which are susceptible to modification of form, size, arrangement of parts, and details of operation. The invention, rather, is intended to encompass all such modification within its spirit and scope, as defined by the claims.
91436-127 MZ/br
Claims (25)
OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:
1. A method of transmitting data from a first computing device to a second computing device over a packet switched network, said method comprising the steps of:
a. forming a first protocol data unit ("PDU") comprising said data at said first computing device;
b. forming at least one subsequent PDUs, comprising said data at said first computing device;
c. transmitting a set of PDUs comprising said first and subsequent PDUs from said first computing device to said second computing device using said network; and d. while receipt of said first PDU formed in step a. has not been acknowledged to said first computing device by said second computing device, re-transmitting said first PDU from said first computing device to said second computing device.
a. forming a first protocol data unit ("PDU") comprising said data at said first computing device;
b. forming at least one subsequent PDUs, comprising said data at said first computing device;
c. transmitting a set of PDUs comprising said first and subsequent PDUs from said first computing device to said second computing device using said network; and d. while receipt of said first PDU formed in step a. has not been acknowledged to said first computing device by said second computing device, re-transmitting said first PDU from said first computing device to said second computing device.
2. The method of claim 1, wherein said subsequent PDUs are transmitted at substantially equal time intervals.
3. The method of claim 2, wherein said time intervals are between 200 and 1200 ms.
4. The method of claim 1, wherein said network comprises an internet and said first PDU is transmitted and re-transmitted in accordance with the transmission control protocol.
5. The method of claim 4, wherein said subsequent PDUs are transmitted in accordance with the user datagram protocol.
6. The method of claim 5, wherein said set comprises four PDUs.
7. The method of claim 1, wherein said first PDU and said subsequent PDUs, each comprise a unique re-transmission count indicator.
8. The method of claim 7, wherein each of said first PDU and said subsequent PDUs comprise an identical PDU sequence number.
9. A method of receiving data within a protocol data unit ("PDU") at a second computer comprising the steps of:
a. establishing a data exchange session with a first computer;
b. receiving from said first computer, a plurality of packets, each of said packets comprising a PDU in a set of PDUs, each of said PDUs comprising said data and an identical PDU sequence number, only some of said packets further comprising a packet sequence number; and c. processing one of said PDUs received in step b. and discarding the remaining PDUs received in step b.
a. establishing a data exchange session with a first computer;
b. receiving from said first computer, a plurality of packets, each of said packets comprising a PDU in a set of PDUs, each of said PDUs comprising said data and an identical PDU sequence number, only some of said packets further comprising a packet sequence number; and c. processing one of said PDUs received in step b. and discarding the remaining PDUs received in step b.
10. The method of claim 9, further comprising d. acknowledging receipt of said packets comprising said packet sequence number to said first computer.
11. The method of claim 10, wherein each of said PDUs in said set further comprises a unique re-transmission count indicator.
12. The method of claim 10, wherein said network comprises an internet and said packet comprising said sequence number is received using the transmission control protocol.
13. The method of claim 12, wherein at least one of said packets containing a PDU in said set is received using the user datagram protocol ("UDP").
14. The method of claim 9, further comprising the steps of:
d. receiving a set of additional PDUs comprising additional identical data and identical PDU sequence numbers from said first computer;
e. processing one of said PDUs received in step d. and discarding the remaining PDUs received in step d.
d. receiving a set of additional PDUs comprising additional identical data and identical PDU sequence numbers from said first computer;
e. processing one of said PDUs received in step d. and discarding the remaining PDUs received in step d.
15. The method of claim 14, wherein step a. comprises negotiating logical UDP ports to be used during said session.
16. The method of claim 15, further comprising the step of:
f. repeating steps d. and e. for further additional PDUs comprising further additional data.
f. repeating steps d. and e. for further additional PDUs comprising further additional data.
17. The method of claim 16, further comprising the step of g. maintaining an indicator of an expected PDU sequence number;
h. incrementing said indicator after receipt of PDUs comprising said PDU sequence number;
and wherein PDUs that do not comprise said expected PDU sequence number are discarded in steps c. and e.
h. incrementing said indicator after receipt of PDUs comprising said PDU sequence number;
and wherein PDUs that do not comprise said expected PDU sequence number are discarded in steps c. and e.
18. A method of exchanging data between a second computing device and a first computing device during a data exchange session, said method comprising the steps of:
a. transferring an indicator of a session commencement from said second computing device to said first computing device;
b. transferring from one of said first and second computing devices to the other of said first and second computing devices indicators of first and second logical ports to be used during said session;
c. transferring a PDU comprising said data from said first computing device to said second computing device using said first logical port; and d. transferring a PDU comprising said data from said first computing device to said second computing device using said second logical port.
a. transferring an indicator of a session commencement from said second computing device to said first computing device;
b. transferring from one of said first and second computing devices to the other of said first and second computing devices indicators of first and second logical ports to be used during said session;
c. transferring a PDU comprising said data from said first computing device to said second computing device using said first logical port; and d. transferring a PDU comprising said data from said first computing device to said second computing device using said second logical port.
19. The method of claim 18, wherein said first PDU is transferred using a reliable protocol.
20. The method of claim 19, wherein said first PDU is transferred using the transport control protocol ("TCP"), and said second PDU is transferred using the user datagram protocol ("UDP"), and wherein said first logical port is a TCP port, and said second logical port is a UDP port.
21. A computer readable medium comprising a software program that when loaded into memory of a computer comprising a network interface, adapts said computer to:
a. form a first protocol data unit ("PDU") comprising data;
b. form at least one subsequent PDUs, comprising data identical to data of said first PDU;
c. transmit a set of PDUs comprising said first and subsequent PDUs from said computer to a second computing device using said network interface; and d. while receipt of said first PDU has not been acknowledged to said computer by said second computing device, re-transmitting said first PDU to said second computing device.
a. form a first protocol data unit ("PDU") comprising data;
b. form at least one subsequent PDUs, comprising data identical to data of said first PDU;
c. transmit a set of PDUs comprising said first and subsequent PDUs from said computer to a second computing device using said network interface; and d. while receipt of said first PDU has not been acknowledged to said computer by said second computing device, re-transmitting said first PDU to said second computing device.
22. A method of operating first and second computing devices interconnected by a packet switched data network, during a data exchange session, said method comprising the steps of:
a. establishing said data exchange session between said second computing device and said first computing device;
b. transmitting a set of at least two PDUs in packets from said first computing device to said second computing device, each PDU in said set of PDUs comprising identical data and an identical PDU
sequence number, at least one packet further comprising a packet sequence number;
c. processing one PDU in said set at said second computing device;
d. acknowledging receipt of packets that comprise packet sequence numbers, to said first computing device.
a. establishing said data exchange session between said second computing device and said first computing device;
b. transmitting a set of at least two PDUs in packets from said first computing device to said second computing device, each PDU in said set of PDUs comprising identical data and an identical PDU
sequence number, at least one packet further comprising a packet sequence number;
c. processing one PDU in said set at said second computing device;
d. acknowledging receipt of packets that comprise packet sequence numbers, to said first computing device.
23. A computer comprising:
a. a processor;
b. a network interface in communication with said processor, for connection with a data network;
c. persistent memory in communication with said processor, said memory comprising software adapting said computer to:
i. form a first protocol data unit (PDU) comprising data;
ii. form at least one subsequent PDUs, comprising said data;
iii. transmit a set PDUs comprising said first and subsequent PDUs to a second computing device using said network interface; and iv. while receipt of said first PDU has not been acknowledged to said computer, by said second computing device, re-transmit said first PDU from said first computing device to said second computing device.
a. a processor;
b. a network interface in communication with said processor, for connection with a data network;
c. persistent memory in communication with said processor, said memory comprising software adapting said computer to:
i. form a first protocol data unit (PDU) comprising data;
ii. form at least one subsequent PDUs, comprising said data;
iii. transmit a set PDUs comprising said first and subsequent PDUs to a second computing device using said network interface; and iv. while receipt of said first PDU has not been acknowledged to said computer, by said second computing device, re-transmit said first PDU from said first computing device to said second computing device.
24. A computer comprising:
a. a processor;
b. a network interface in communication with said processor, for connection with a data network;
c. memory in communication with said processor, said memory comprising software adapting said computer to:
a. establish a data exchange session with a second computer;
b. receive from said second computer, a plurality of packets, each of said packets comprising a PDU in a set of PDUs, each of said PDUs comprising said data and an identical PDU sequence number, only some of said packets further comprising a packet sequence number; and c. process one of said PDUs received in step b. and discard the remaining PDUs received in step b.
a. a processor;
b. a network interface in communication with said processor, for connection with a data network;
c. memory in communication with said processor, said memory comprising software adapting said computer to:
a. establish a data exchange session with a second computer;
b. receive from said second computer, a plurality of packets, each of said packets comprising a PDU in a set of PDUs, each of said PDUs comprising said data and an identical PDU sequence number, only some of said packets further comprising a packet sequence number; and c. process one of said PDUs received in step b. and discard the remaining PDUs received in step b.
25. A computing device interconnected with a network, said device comprising:
i. means for forming a first protocol data unit (PDU) comprising data;
ii. means for forming at least one subsequent PDUs, comprising said data;
iii. means for transmitting a set of PDUs comprising said first and subsequent PDUs to a second computing device using said network interface; and iv. means for re-transmitting said first PDU to said second computing device, while receipt of said first PDU has not been acknowledged to said computing device, by said second computing device.
i. means for forming a first protocol data unit (PDU) comprising data;
ii. means for forming at least one subsequent PDUs, comprising said data;
iii. means for transmitting a set of PDUs comprising said first and subsequent PDUs to a second computing device using said network interface; and iv. means for re-transmitting said first PDU to said second computing device, while receipt of said first PDU has not been acknowledged to said computing device, by said second computing device.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002246134A CA2246134C (en) | 1998-08-31 | 1998-08-31 | Enhanced network protocol |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002246134A CA2246134C (en) | 1998-08-31 | 1998-08-31 | Enhanced network protocol |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2246134A1 CA2246134A1 (en) | 2000-02-29 |
| CA2246134C true CA2246134C (en) | 2005-11-01 |
Family
ID=29409822
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002246134A Expired - Fee Related CA2246134C (en) | 1998-08-31 | 1998-08-31 | Enhanced network protocol |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2246134C (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090113081A1 (en) * | 2007-10-24 | 2009-04-30 | National Electronics & Watch Co. Ltd. | Communication apparatus, communication protocol, and methods of communicating between devices |
-
1998
- 1998-08-31 CA CA002246134A patent/CA2246134C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2246134A1 (en) | 2000-02-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0912028B1 (en) | Mechanism for dispatching packets via a telecommunications network | |
| US6338091B1 (en) | System for optimistic transmission flow control including receiver data discards upon inadequate buffering condition | |
| US7474619B2 (en) | Method and apparatus for providing fragmentation at a transport level along a transmission path | |
| US6249530B1 (en) | Network bandwidth control | |
| EP0796533B1 (en) | Multi-processor environments | |
| US6091710A (en) | System and method for preventing data slow down over asymmetric data transmission links | |
| CN113711547A (en) | System and method for facilitating efficient packet forwarding in a Network Interface Controller (NIC) | |
| US8090859B2 (en) | Decoupling TCP/IP processing in system area networks with call filtering | |
| US7103674B2 (en) | Apparatus and method of reducing dataflow distruption when detecting path maximum transmission unit (PMTU) | |
| Sanders et al. | The Xpress transfer protocol (XTP)—a tutorial | |
| US20020146016A1 (en) | Transferring transmission control protocol packets | |
| EP1323264A2 (en) | Mechanism for completing messages in memory | |
| US7359326B1 (en) | Method for splitting data and acknowledgements in a TCP session | |
| Natarajan et al. | SCTP: An innovative transport layer protocol for the web | |
| US7480301B2 (en) | Method, system and article for improved TCP performance during retransmission in response to selective acknowledgement | |
| Ahmad et al. | Enhancing fast TCP’s performance using single TCP connection for parallel traffic flows to prevent head-of-line blocking | |
| US8578040B2 (en) | Method, system and article for client application control of network transmission loss tolerance | |
| US7000024B1 (en) | Systems and methods for providing transmission control protocol communications | |
| CA2246134C (en) | Enhanced network protocol | |
| WO2003069836A1 (en) | Multicasting selective repeat protocol | |
| Mneimneh | Computer Networks UDP and TCP | |
| AU689005C (en) | Multi-processor environments | |
| Elsayed et al. | Synchronization algorithm for SCTP network | |
| Gunes et al. | UTCP: Unordered transmission control protocol (TCP) for high throughput bulk data transfer | |
| Maupin | Managing network interfaces: Increasing end-point performance in a congested network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |