字元填充的首尾定界符法

2021-09-05 04:34:44 字數 4302 閱讀 3132

以下內容摘自筆者編著的

《網路工程師必讀——網路工程基礎》

一書:<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

該同步方法是用一些特定的字元來定界一幀的起始與終止,充分解決了錯誤發生之後重新同步的問題。

1. 同步原理

在這種幀同步方式中,為了不使資料資訊位中與特定字元相同的字元被誤判為幀的首尾定界符,可以在這種資料幀的幀頭填充乙個轉義控制字元(

dle stx

,data link escape – start of text

),在幀的結尾則以

dle etx

(data link escape – end of text

)結束,以

示區別,從而達到資料的透明性。若幀的資料中出現

dle字元,傳送方則插入乙個

「dle」

字元,接收方會刪除這個

dle字元。如現在要傳送乙個如圖

7-3(

a)的字元幀,在幀中間有乙個

「dle」

字元資料,所以傳送時會在其前面插入乙個

「dle」

字元,如圖(

b)所示。在接收方接收到資料後會自己刪除這個插入的

「dle」

字元,結果仍得到原來的資料,但幀頭和幀尾仍在,予以區別,如圖(

c)所示。

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /> 圖

7-3

字元填充的首尾定界原理

在以前,這種同步方式中,起始和結束字元是不同的(如起始字元為

dle,而結束字元是

dle etx

),但是近幾年,絕大多數協議傾向於使用相同的字元來標識起始和結束位置。按這樣的做法,在接收方丟失了同步,則只需搜尋一下標誌符就能找到當前幀的結束位置。兩個連線的標誌符代表了當前幀的結束和下一幀的開始。  

但這種同步方式也不是完美的,也會發生嚴重的問題。當標誌符的位模式出現在資料中時,這時同步問題就可能發生了。這種位模式往往會干擾正常的幀分界。解決這一問題的辦法是在傳送方的資料鏈路層傳輸的資料中,在與分界標誌符位模式一樣的字元中插入乙個轉義字元(如

esc)。接收方的資料鏈路層在將資料送給網路層前刪除這種轉義字元。因此,成幀用的標誌字元與資料中出現的相同位模式字元就可以分開了,只要看它前面有沒有轉義字元即可。  

如果轉義字元出現在資料中間,同樣需要用轉義字元來填充。因此任何單個轉義字元一定是轉義序列的一部分,而兩個轉義位元組則代表資料中的自然出現的乙個轉義字元。具體參見圖

7-3。  

2. 示例介紹

這種幀同步方法只能用於較為少用的面向字元型協議,

典型代表是

ibm公司的二進位制同步通訊協議(

bsc)和

ppp協議。它的特點是一次傳送由若干個字元組成的資料塊,而不是只傳送乙個字元,並規定了

10個字元作為這個資料塊的開頭與結束標誌,以及整個傳輸過程的控制資訊。由於被傳送的資料塊是由字元組成,所以也被稱之為

「向字元的協議」。

bsc協議用ascii

和ebcdic

字符集定義的傳輸控制字元來實現相應的功能。這些傳輸控制字元的標記、名字及

ascii

碼值和ebcdic

碼值見表

7-1。

表7-1   bsc

協議的10

個傳輸控制字元

標記

soh  

stx  

etx  

eot  

enq  

ack 

delnak 

syn 

etb名稱

序始文始

文終送畢

詢問確認

轉義否認

同步塊終

ascii

碼值01h  

02h 

03h  

04h  

05h  

06h 

10h 

15h 

16h 

17hebcdic

碼值

01h 

02h 

03h 

37h 

2dh2eh 

10h 

3dh 

32h 

26h

lsoh

(start of head

):報頭開始標誌,用於表示報文的標題資訊或報頭的開始。

lstx

(start of test

):文字開始標誌,標誌標題資訊的結束和報關文字的開始。

letx

(end of text

):文字終止標誌,標誌報文文字的結束。

leot

(end of transmission

):傳送完畢標誌,用以表示乙個或多個文字的結束,並拆除鏈路。

lenq

(enquire

):詢問標誌,用以請求遠端站給出響應,響應可能包括站的身份或狀態。

lack

(acknowledge

):確認標誌,由接收方發出的作為對正確接收到報文的響應。

ldle

(data link escape

):轉義標誌,用以修改緊跟其後的有限個字元的意義。在

bsc協議中,實現透明方式的資料傳輸,或者當

10個傳輸控制字元不夠用時,提供新的轉義傳輸控制字元。

lnak

(negative acknowledge

):否認標誌,由接收方發出的,作為對未正確接收的報文的響應。

lsyn

(synchronous

):字元同步標誌,在同步協議中,用以實現節點之間的字元同步,或用於在無資料傳輸時保持該同步。

letb

(end of transmission block

):塊終或組終止標誌,用以表示當報文分成多個資料塊的結束。

bsc協議將在鏈路上傳輸的資訊分為資料和監控報文兩類。監控報文又可分為正向監控和反向監控兩種。每一種報文中至少包括乙個傳輸控制字元,用以確定報文中資訊的性質或實現某種控制作用。資料報文一般由報頭和文字組成。文字是要傳送的有效資料資訊,而報頭是與文字傳送和處理有關的輔助資訊,報頭有時也可不用。對於不超過長度限制的報文可只用乙個資料塊傳送,對較長的報文則分作多塊傳送,對較長的報文則分作多塊傳送,每乙個資料塊作為乙個傳輸單位。接收方對於每乙個收到的資料塊都要給以確認,傳送方收到反回的確認後,才能傳送下乙個資料塊。

bsc協議的資料塊有如下四種格式: l

不帶報頭的單塊報文或分塊傳輸中的最後一塊報文

這種報文格式為:

syn | syn  | stx |

報文|  etx |  bcc l

帶報頭的單塊報文

這種報文的格式為:

syn | syn | soh |

報頭| stx |

報文| etx | bcc l

分塊傳輸中的第一塊報文

這種報文格式為:

syn | syn | soh |

報頭| stx |

報文| etb | bcc l

分塊傳輸中的中間報文

這種報文格式為:

syn | syn | stx |

報文| etb | bcc

從以上資料報文格式可以看出,

bsc協議中所有傳送的資料均跟在至少兩個

syn字元之後,以使接收方能實現字元同步。報頭欄位的包識別符及位址。所有資料塊在塊終限定符(

etx或

etb)之後還有塊校驗字元

bcc(

block check character

),bcc

可以是垂直奇偶校驗或者說16位

crc,校驗範圍從

stx開始到

etx或

etb為止。

當傳送的報文是二進位制資料庫,而不是字串時,二進位制資料中形同傳輸控制字元的位元串將會引起傳輸混亂。為使二進位制資料中允許出現與傳輸控制字元相同的資料(即資料的透明性),可在各幀中真正的傳輸控制字元(

syn除外)前加上

dle轉義字元;在傳送時,若文字中也出現與

dle字元相同的二進位制位元串,則可插入乙個外加以標記。在接收端則進行同樣的檢測,若發現單個的

dle字元,則可知其後為傳輸控制字元;若發現連續兩個

dle字元,則知其後的

dle為資料,在進一步處理前將其中乙個刪去。

字元填充的首尾定界符法

7.2.2 字元填充的首尾定界符法 該同步方法是用一些特定的字元來定界一幀的起始與終止,充分解決了錯誤發生之後重新同步的問題。1 同步原理 在這種幀同步方式中,為了不使資料資訊位中與特定字元相同的字元被誤判為幀的首尾定界符,可以在這種資料幀的幀頭填充乙個轉義控制字元 dle stx,data lin...

PHP中的定界符格式

nowdoc 單引號定界符 abc可以是任合內容,放在單引號中 c abc 這裡可以是任合內容 我是歷的苛奪基 本原則葉落歸根在運 輸費艱難田 abc echo c heredoc 雙引號定界符 abc可以是任合內容,放在雙引號中或是不加引號 c 這裡可以是任合內容 我是歷的苛奪基 本原則葉落歸根在...

php 定界符格式引起的錯誤

錯誤 parse error syntax error,unexpected end in h w程式設計客棧amp www testing test 2.1.4.php on line 16 錯誤源 複製 如下 str 測試字串 測kcxeuk試字串 測試字串 eod echo str 為定界符定...