簡體   English   中英

Telnet over half-duplex comms link - negotiation parameters

[英]Telnet over half-duplex comms link - negotiation parameters

我們的嵌入式系統需要一個Telnet(串行)接口,由於硬件/傳統系統,它通過半雙工鏈路(RS485)工作。 是的,我知道 - 不,我們無法改變它,業界喜歡這樣。

這樣做的問題是,當我們向終端發送一連串文本時,用戶可以按下按鈕並在線路上發送數據。

Telnet支持IAC-> GA(Go Ahead)命令向用戶終端發信號它可以開始發送數據,但是我讀過的任何RFC中都沒有關於告訴用戶終端停止發送數據的信息,所以我們可以刷新屏幕。

不幸的是,超過1973年的所有RFC都假設將使用SGA( 抑制前進 )模式,因此很少提及。 遺憾的是,似乎沒有單個RFC或其他文檔實際涵蓋整個協議。

有沒有人有任何信息/鏈接更全面地記錄telnet協議(或只是Go Ahead行為)? 我意識到其中一些可能寫在帶有綠色條紋的羊皮紙上;)

重新編輯:為什么這個編程問題的“偏離主題”關閉? Telnet是OSI模型的第7層你知道嗎...

啊...... RS-485 ......我記得很清楚! :-)

GA定義被破壞(參見http://tools.ietf.org/html/rfc596 ),但對於串行實現應該沒問題,因為沒有分解的分解。

您要求的是“反向休息”:

“反向中斷”是通過半雙工路徑連接到終端的計算機可以在先前放棄它之后重新獲得對進一步打字的路徑的控制的手段。

就其本質而言,“中斷”(反向或其他)必須在半雙工連接上是帶外的,因為它需要能夠隨時發送。

編輯:聊天結果的新信息:但是,如果您不希望中斷實際傳輸( RFC393 ,反向中斷情況“b”), 並且帶有前進令牌的一方不會切換硬件“發送”模式除了實際發送時(即使沒有發送數據,RS-485在此模式下也無法接收) 並且偶爾會發生損壞/截斷傳輸, 並且 telnet程序正確實現了這個相當不尋常的角落情況, 那么在帶內發送此代碼可能是可以接受的。

我能想到的另一種解決方法是破解客戶端Telnet程序,即使沒有其他任何東西可以發送,也會定期向服務器發送一個“反復”數據包。 這將允許服務器進行更新並作為回報“先行”; 它有點像“令牌戒指”。 您甚至不必延遲 - 當收到“預先”時,發送所有待處理數據(可能是無)然后返回“正常”。

可能的替代方案:

既然你也控制了ser-> ip設備,為什么不在服務器和設備之間簡單地使用專用協議呢?

  • 服務器發送STX data stream ETX

  • 客戶端發送STX data stream ETX

  • 不要拖延地重復

如果任何一方的數據緩沖區中沒有數據,那么它只是一個STX ETX對,有效地告訴對方“繼續”。 如果在250ms內沒有任何東西來自另一側,請重新發送ETX

您甚至可以通過在檢測到錯誤的情況下將STX data stream ETX CRC1 CRC2NAK (而不是STX ... )應答一起進行擴展以進行錯誤檢測,並導致重新傳輸整個最后一個數據包。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM