Multiplex communications – Communication techniques for information carried in plural... – Adaptive
Reexamination Certificate
1999-03-30
2004-06-22
Ton, Dang (Department: 2661)
Multiplex communications
Communication techniques for information carried in plural...
Adaptive
C370S231000, C370S395210, C370S395410, C370S449000
Reexamination Certificate
active
06754228
ABSTRACT:
FIELD OF INVENTION
BACKGROUND
The internet is a communication network that comprises a number of different service layers. The lowest layer is the hardware layer, onto which software layers of different functions are added. As an example, the world wide web (WWW) is a layer above the basic internet layer provided by the internet protocol (IP).
The internet is a packet exchange network, where the basic structure of information is determined by the internet protocol. A protocol is a set of rules to which two partners in an intended communication must adhere to thereby enable the communication. The internet protocol regulates addressing, i.e., it ensures that routers between two communication points are capable of sending data packets to their destination. An IP packet consists of a header, which contains information relating to data being sent, and a body containing the data itself.
In order to facilitate the reliable transmission of data between two ends of a communication, a further protocol is provided, the transmission control protocol (TCP). TCP takes the information to be sent and divides it into given segments. Each segment receives a number so that the receipt of a given segment can be acknowledged by the receiver, and the receiver is able to put the information together in the correct order. TCP has its own header carrying its own information that is used by this protocol. The TCP packets are sent over the internet by being placed into IP packets, i.e. the TCP packet is encapsulated in the (lower layer) IP packet. This is why the transport of packets across the internet is often referred to as TCP/IP.
FIG. 2
shows a body of data
100
divided into 8 data segments of equal size, respectively numbered 1 to 8. As an example, the body
100
could have a size of 8192 bytes so that each data segment would comprise 1024 bytes. The information that actually needs to be sent will usually be somewhere between 7168 bytes and 8192 bytes. The final data segment
8
will simply be filled by “padding” to thereby achieve equal sized data segments. The precise size of a single data segment is not fixed to the above example of 1024 bytes, but will be appropriately selected by a sending system in accordance with given constraints, e.g., the maximum transmission unit (MTU) allowed by a specific link.
The term “window” describes an amount of bytes, or more generally, a data amount expressed in units of data. According to TCP, the receiver sends an “advertised” or offered window to the sender in response to a packet from the sender that initiates communication. A TCP sender is not allowed to have more unacknowledged packets outstanding than the amount defined by the advertised window. The receiver sends an advertised window in each acknowledgment message or packet.
The advertised window usually corresponds to the input buffer capacity on the receiver side. The function of the advertised window is to prevent a fast sender from letting the input buffer of a slow receiver overflow.
The mechanism of sliding window control will be explained by referring to
FIGS. 3 and 4
, which illustrate an example of sending the data amount
100
shown in
FIG. 2
, and by referring to
FIGS. 5 and 6
, which illustrate the principal of sliding window control.
FIG. 3
illustrates an example of the transmission of the 8 segments of data shown in
FIG. 2
, where the sender is shown on the left hand side and the receiver is shown on the right hand side. Each arrow indicates the sending of a packet, where the double lined arrows correspond to packets containing data segments, as will be explained in more detail below. The sending of individual packets is illustrated by reference labels S
1
to S
20
, where each act of sending from either of the two sides is also referred to as a segment. This indicates that generally one packet containing the data of
FIG. 2
will contain one data segment. The direction of time is from top to bottom.
The sequence shown in
FIG. 3
is a simplification for explaining the flow control, and therefore not all packets carry a reference label, as these relate to other aspects of communication. Also some of the segments carrying reference labels also carry more data, but as this supplementary data again relates to other aspects of the communication than flow control, it is not illustrated here. The notation X:Y(Z) means that bytes number X to Y are sent, which make up a total of Z. Ack X means that the receipt of bytes up to number X is acknowledged, and Win X means that a window of X bytes is advertised.
The segments S
1
to S
3
between sender and receiver relate to the establishment of communication, and will not be explained further, except that the receiver announces a window of 4096 bytes in segment S
2
. In segments S
4
to S
7
the sender sends the first three data segments 1 to 3, i.e. the bytes 1 to 1025, 1025 to 2049 and 2049 to 3073. The receiver acknowledges the receipt of the bytes up to 2049 in S
7
, where S
7
again advertises a window of 4096. Why the receiver does not acknowledge up to 3073 is of no importance for explaining flow control. It is e.g. possible that this data segment is delayed in processing on the receiving side. In segment S
8
the receiver acknowledges up to 3073 and advertises a window of 3073. Again, the reason for this is of no importance for the explanation of flow control. It is e.g. possible that there is still a delay in the receiver's input buffer, and therefore the reduced window serves to prevent overflow. In segment S
9
the sender sends one more data segment, namely bytes 3073 to 4097. These are acknowledged in segment S
10
, in which again a window of 4096 is advertised. The sender then sends three data segments in segments S
11
to S
13
, namely bytes 4097 to 5121, 5121 to 6145 and 6145 to 7169. In segment S
14
, the receiver only acknowledges up to byte 6145, but continues to advertise a window of 4096. In segment S
15
, the sender sends the last data segment consisting of bytes 7169 to 8193, where the receiver acknowledges the receipt of all bytes up to 8193 in segment S
16
. The remaining exchanges S
17
to S
20
do not relate to flow control.
As can be seen, not every data segment needs to be acknowledged individually, the receiver can also acknowledge the receipt of a number of data segments up to a given segment with one acknowledge message.
FIG. 5
shows the principle of sliding window based flow control. The numbers
1
to
11
refer to data segments, e.g. these can be the data segments shown in
FIG. 2
, or simply be a given number of bytes. With respect to the explanation of window based flow control, it is only important to note that the window
200
covers a certain amount of data, where the control window between left edge
201
and right edge
202
covers data segments
4
to
9
. In the example of
FIG. 5
the control window is the advertised window. (Another type of control window will be described later.) The position of the left edge of the window
200
is determined by the number of data segments already sent (by the sender) and acknowledged (by the receiver). In
FIG. 5
, this means that data segments
1
to
3
have been sent and acknowledged.
Although the data flow above is explained in connection with the example of a sequence of segments, it should be noted that TCP is a stream oriented protocol, such that the sequence base is in terms of bytes. Therefore the acknowledgment messages from the receiver do not indicate received segments, much rather they indicate up to which byte of the sequence data has been received.
The sender calculates the usable window, i.e. the amount of data that can be sent, as the difference between the total window size and the amount of data that has been sent but not yet acknowledged. In
FIG. 5
, the usable window from divide
203
to right edge
202
covers data segments
7
to
9
. Therefore, these data can be sent. The data segments beyond the right edge
202
, i.e.
10
,
11
, etc., cannot be sent until the window moves to cover them. The movement of the window shall be explained
Phan Tri H.
Ton Dang
LandOfFree
Method and device for data flow control does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and device for data flow control, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and device for data flow control will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3329137