嵌入式設備的服務器架構

Question

我正在研究嵌入式ARM平台的服務器應用程序。 ARM板連接到系統將一致輪詢的各種數字IO，ADC等。 它目前正在運行Linux內核，其硬件接口是作為驅動程序開發的。 該想法是具有客戶端應用程序，其可以連接到嵌入式設備並在更新時接收傳感數據並向設備發出命令（關閉傳感器1，重啟傳感器2等）。 假設通過典型的ioctl完成對傳感設備的訪問。

現在我的問題涉及在嵌入式設備上運行的此服務器應用程序的設計/體系結構。 起初我想使用像libevent或libev這樣的輕量級C事件處理庫。 應用程序將優先考慮傳感器輪詢事件（然后在輪詢完成后將信息發送到客戶端）並在接收到客戶端命令時（通過典型的TCP套接字）處理客戶端命令。 服務器通常只有一個連接，但最多可能有十幾個，但不是幾千個連接。 這是設計這樣的東西的最佳方法嗎？ 在我列出的兩個事件處理庫中，對嵌入式應用程序更好，還是有其他選擇？

正在考慮的另一種方法是多線程應用程序，其中傳感器輪詢在優先級/阻塞線程中完成，該線程讀取傳感數據並且每個客戶端連接在單獨的線程中處理。 感知數據被更新為某種緩沖區/數據結構，連接線程處理將數據發送到客戶端並處理客戶端命令（我猜你仍然需要在這些線程中進行排序的事件循環來監視傳入的命令） 。 是否有任何庫或典型的軟件包可以幫助設計這樣的應用程序，或者這是你必須從頭開始的東西？

你會如何設計我想要完成的任務？

Answer 1

我會使用一個unix域套接字 - 並自己編寫庫，看不到使用libvent的任何優點，因為應用程序與linux綁定，而libevent也適用於數百個連接。 您可以使用守護程序中的單個線程執行所有要執行的操作。 吻。

對於只需要編寫線程的優先級隊列，您不需要專用的主線程，因此它始終先處理高優先級事件。

就庫而言，您可能會受益於Google的協議緩沖區 （用於序列化和表示您的協議） - 但它只有C ++的一流支持，並且線上（序列化）格式有點簡單的位移到數字數據。 我懷疑它會增加任何嚴重的開銷。 然而另一種選擇是ASN.1（ asn1c ）。

Answer 2

我的建議是您的第二個提案的修改形式。 我會創建一個有兩個線程的服務器。 一個線程輪詢傳感器，另一個線程用於所有客戶端連接。 我已經在嵌入式設備（MIPS） boost :: asio庫中使用了很好的結果。

以異步方式處理所有套接字連接的單個線程通常可以輕松處理負載（當然，這取決於您擁有的客戶端數量）。 然后它將提供它在共享緩沖區上的數據。 為了減少互斥鎖的數量和復雜性，我將創建兩個緩沖區，一個是“活動”而另一個是“非活動”，還有一個標志來指示當前活動緩沖區。 輪詢線程將讀取數據並將其放入非活動緩沖區。 當它完成並創建了“一致”狀態時，它將翻轉標志並交換活動和非活動緩沖區。 這可以原子方式完成，因此不需要比這更復雜的東西。

設置起來非常簡單，因為你幾乎只有兩個線程對另一個一無所知。