日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

對(duì)于IMP/HOST 協(xié)議的改動(dòng)的注釋

云知道


本篇RFC主要的是對(duì)于RFC687進(jìn)行似乎有道理的改動(dòng)的意見集合 ， 同時(shí)也可以作為對(duì)
RFC690的注釋 。
現(xiàn)在的主要的問題 ， 就好象Postel所指出的那樣 ， 在于改動(dòng)后的IMP和HOST傳輸?shù)那?br /> 導(dǎo)字符的總長度剛好為120位 ， 這個(gè)數(shù)字并不是8或者36的整數(shù)倍 。
一個(gè)可以想到的解決方案是將HOST到HOST協(xié)議的前導(dǎo)字符的長度增加24位 ， 使得它的
總長度達(dá)到144位 。但是這里依舊存在一個(gè)問題 ， 就是在進(jìn)行這樣的改動(dòng)之后 ， IMP方必須
能夠插入或者刪除這多出來的24個(gè)位 ， 來進(jìn)行144位前導(dǎo)字符和120位前導(dǎo)字符之間的轉(zhuǎn)化 。
上述解決方案中存在的這個(gè)問題 ， 是相當(dāng)明顯的 。
更好的解決方案是改變IMP方前導(dǎo)字符的長度 ， 我提議用104位長度代替原來的80位長
度 。不過104位長度并不是一個(gè)IMP的字的長度的整數(shù)倍 ， 這確實(shí)是一個(gè)問題 。但是假如我
們使用以下的法則的話 ， 解決這個(gè)問題并不是很難的事情 。
1.決不用最后的8位傳遞信息 。
2.網(wǎng)絡(luò)沒有被要求將它們從數(shù)據(jù)源傳遞到目的地 ， 或者將它們返回到數(shù)據(jù)源
3.當(dāng)發(fā)送不同于零的類型的消息（即不規(guī)則消息）的時(shí)候 ， IMP被答應(yīng)發(fā)送96位 ， 104
位 ， 112位的數(shù)據(jù) ， 具體的選擇看當(dāng)時(shí)IMP的便利而定 。
4.同樣的 ， 假如需要的話 ， 96位和112位也可以作為不規(guī)則消息的前導(dǎo)字符的長度 。
這樣 ， 比較起強(qiáng)制所有的HOST進(jìn)行修改以適應(yīng)新的標(biāo)準(zhǔn)協(xié)議 ， 修改IMP程序 ， 使他們能
夠處理104位的前導(dǎo)字符就是一種更快 ， 同時(shí)也是更便宜的選擇了 。
另外一個(gè)建議是定義一種新的IMP到HOST的消息的類型 。這個(gè)消息應(yīng)當(dāng)擁有一個(gè)包括了
HOST的名字（人類型的字符串（peopletypecharacterstring））和HOST的網(wǎng)絡(luò)地址的表 。
這個(gè)消息應(yīng)當(dāng)在每一次接口重置的時(shí)候進(jìn)行發(fā)送 ， 或者當(dāng)HOST對(duì)IMP發(fā)送了一個(gè)新的請(qǐng)求 ，
以要求得到上述信息的時(shí)候 ， 這個(gè)消息可以作為響應(yīng)被發(fā)送
[ThisRFCwASPutintomachinereadableformforentry]
[intotheonlineRFCarchivesbyAlexMcKenziewith]
[supportfromGTE,formerlyBBNCorp.10/99]

    推薦閱讀