Exit Zen
70
../../principles/reliability.rst:246
English
`NUL`: `0000000` b
0/180 · 18
71
../../principles/reliability.rst:247
English
`BEL`: `0000111` b
0/180 · 18
72
../../principles/reliability.rst:248
English
`CR` : `0001101` b
0/180 · 18
73
../../principles/reliability.rst:249
English
`LF` : `0001010` b
0/180 · 18
74
../../principles/reliability.rst:250
English
`DLE`: `0010000` b
0/180 · 18
75
../../principles/reliability.rst:251
English
`STX`: `0000010` b
0/180 · 18
76
../../principles/reliability.rst:252
English
`ETX`: `0000011` b
0/180 · 18
77
../../principles/reliability.rst:254
English
Some characters are used as markers to delineate the frame boundaries. Many `character stuffing` techniques use the `DLE`, `STX` and `ETX` characters of the ASCII character set. `DLE STX` (resp. `DLE ETX`) is used to mark the beginning (end) of a frame. When transmitting a frame, the sender adds a `DLE` character after each transmitted `DLE` character. This ensures that none of the markers can appear inside the transmitted frame. The receiver detects the frame boundaries and removes the second `DLE` when it receives two consecutive `DLE` characters. For example, to transmit frame `1 2 3 DLE STX 4`, a sender will first send `DLE STX` as a marker, followed by `1 2 3 DLE`. Then, the sender transmits an additional `DLE` character followed by `STX 4` and the `DLE ETX` marker.
0/7810 · 781
78
../../principles/reliability.rst:260
English
**1** **2** **3** **4**
0/230 · 23
79
../../principles/reliability.rst:260
English
`DLE STX` **1** **2** **3** **4** `DLE ETX`
0/430 · 43
80
../../principles/reliability.rst:261
English
**1** **2** **3** **DLE** **STX** **4**
0/390 · 39
81
../../principles/reliability.rst:261
English
`DLE STX` **1** **2** **3** **DLE** `DLE` **STX** `4` `DLE ETX`
0/630 · 63
82
../../principles/reliability.rst:262
English
**DLE STX DLE ETX**
0/190 · 19
83
../../principles/reliability.rst:262
English
`DLE STX` **DLE** `DLE` **STX** **DLE** `DLE` ETX** `DLE ETX`
0/610 · 61
87
../../principles/reliability.rst:304
English
Recovering from transmission errors
0/350 · 35
88
../../principles/reliability.rst:306
English
In this section, we develop a reliable datalink protocol running above the physical layer service. To design this protocol, we first assume that the physical layer provides a perfect service. We will then develop solutions to recover from the transmission errors.
0/2630 · 263
89
../../principles/reliability.rst:308
English
The datalink layer is designed to send and receive frames on behalf of a user. We model these interactions by using the `DATA.req` and `DATA.ind` primitives. However, to simplify the presentation and to avoid confusion between a `DATA.req` primitive issued by the user of the datalink layer entity, and a `DATA.req` issued by the datalink layer entity itself, we will use the following terminology :
0/3990 · 399
90
../../principles/reliability.rst:310
English
the interactions between the user and the datalink layer entity are represented by using the classical `DATA.req` and the `DATA.ind` primitives
0/1430 · 143
91
../../principles/reliability.rst:311
English
the interactions between the datalink layer entity and the framing sub-layer are represented by using `send` instead of `DATA.req` and `recvd` instead of `DATA.ind`
0/1640 · 164
94
../../principles/reliability.rst:334
English
To solve this problem, a reliable protocol must include a feedback mechanism that allows the receiver to inform the sender that it has processed a frame and that another one can be sent. This feedback is required even though there are no transmission errors. To include such a feedback, our reliable protocol must process two types of frames :
0/3430 · 343