如何處理具有多個輸入和輸出的單個文本io流？

Question

所以我正在解決一些問題，一些建議會很好。先有一點背景，請原諒。

我正在通過TL1 protocol查詢網絡設備的管理系統。對於那些不熟悉協議的人來說，最簡單的答案就是通過基於文本的IO流進行通信的「人類可讀」語言。

我使用Spring和Jsch打開一個端口到遠程網元（網元），登錄，運行命令，然後關閉連接。有兩種進入遠程網元的方式，直接（通過ssh網關）如果元素有一個tcp/ip地址（許多隻是osi），或者通過某種類型的ems（管理系統）使用所謂的「北向接口」。

無論哪種方式，程序是相同的。

• 使用Jsch打開一個端口到NE或ems。
• 發送網元前的登錄命令"act-user<tid>:<username>:UniqueId::<password>;"
• 發送命令ex。 "rtrv-alm-all:<tid>:ALL:uniqueid::,,,,;"

• 檢索並處理結果。上述例如可能是這個樣子的結果...

  RTRV-ALM-ALL:foo:ALL:uniqueid;

  CMPSW205 02-01-11 18:33:05

  M uniqueid COMPLD

  "01-01-06:MJ,BOARDOUT-ALM,SA,01-10,12-53-58,,:\"OPA_C__LRX:BOARD EXTRACTED\","

  ;

;很重要，因爲它表示響應的結束。

• 最後註銷並關閉端口。

隨着春天我一直在使用ThreadPoolTaskExecutor相當有效地做到這一點。

直到這個問題上來......

與一個特定的EMS平臺（日立），我碰到一個障礙跑了我的做法。這個EMS通過它可以處理多達80個節點。您連接到端口，然後發出命令登錄到ems，然後運行指向各個NE的命令。與以前相同的過程，但這裏是問題...

在您登錄到ems後，無論是什麼，下一個命令將花費10分鐘完成。直到發生這種情況，所有其他命令都被阻止。在初始等待之後，所有其他命令都可以快速工作似乎沒有辦法打敗這種行爲（我懷疑在此期間有一些NE自動發現發生）。

現在我的問題的重點......

因此，我對這個平臺的下一個方法是連接到ems，登錄到它，並保持連接打開，並將命令傳遞給各個NE。這意味着應用程序（基於Web）第一次加載後延遲10分鐘，但在此之後會很好。

我遇到的問題是如何最好地做到這一點。使用單個基於文本的iostream傳遞這些東西看起來像是一個很大的瓶頸，再加上多個用戶將使用該應用程序，我該如何處理針對這個單一iostream的多個命令和響應？我可以在這個ems上打開幾個iostreams（也許最多6個），但是這也會使得分析哪些地方變得複雜。

任何意見的方向將不勝感激。

Answer 1

看看每個EMS使用一個進程，以便與每個EMS的通信是分開的。這至少會確保與其他ems的通信不受這個問題的影響。

您將不得不建立某種命令排隊系統，以便發送到Hitachi ems的命令在完成之前不會阻止用戶界面。要麼是這樣，要麼你必須在開始使用它之前將10分鐘的延遲放入客戶端軟件，或者在處理日立的接口部分延遲10分鐘。

也許這將是一個很好的策略來調出連接，並立即發送某種ping或站點保持空閒命令 - 這是一種良性的做法，你不關心響應，或者沒有響應，但會觸發10分鐘延遲結束。您的用戶可以熟悉這10分鐘的延遲，並且至少在獲得咖啡之前啓動應用程序。

如果您可以在應用程序設計中以某種方式將日立與其他ems進行隔離，那麼這將確保10分鐘延遲僅在與日立接口時才存在。您可以連接併發布虛擬命令，並將Hitachi置於某種「連接」狀態，在該狀態下命令無法使用，直到結果進入，然後將狀態更改爲就緒狀態，以便用戶與其進行交互。

---

另一種方法是開發某種中間件組件 - 我不知道你是否已經這樣做了。如果客戶端都是基於網絡的，那麼你可以在網絡服務器上運行一個通信件，該服務器從客戶端獲取連接，並通過與所有ems通信的網絡服務器上的一塊管道連接它們。當這件作品在網絡服務器上啓動時，它可以連接到每個EMS併發送一些啓動10分鐘定時器的初始ping命令。完成此操作後，Web服務器上的部分可以每隔一段時間發送一次保持活動消息，再次使用某種虛擬命令，以保持套接字的活躍狀態，以便不必重新設置並再次等待10分鐘的等待時間。當用戶打開網站時，他們可以與這個中間件服務器通信，將這些請求轉發給適當的ems，並將響應轉發回客戶端 - 全部通過已經打開的連接。