在實名制這塊其主要的技術在於硬件設備與服務器之間的通信，最理想的狀態是每一台硬件設備都擁有一個廣域網的ip，這樣服務器和設備可以點對點直接通信。但是理想和現實差距很大，受制於ipv4的數量限制導致廣域網的ip價格高昂，無法大面積的在設備中應用。沒有廣域網ip情況下設備想和服務器進行數據交互，就變得非常復雜，就目前來講只有三種比較主流的數據交互方案。
第一種方案是使用TCP、UDP協議通信，設備發送UDP數據詢問服務器端可有數據需要下載，如果有數據需要下載設備端就發起TCP請求來下載數據。這種方案的好處是只需要服務器端擁有廣域網IP就可以進行正常的數據交換。但是這個方案數據交互非常緩慢.每交互一次就需要間隔數十秒。
第二種方案是使用MQ協議通信，設備端訂閱mq的某一個頻道，服務器只需要把需要發送給硬件設備的數據推送到消息隊列中，設備收到推送會自動下載數據。這種通信方式效率很高在物聯網這塊應用也很廣泛，是比較優秀的通信方案選擇，但是技術實現難度很高、應用成本也很高。
第三種方案是使用中間層，我稱之為稱為數據交互管理器。數據交互管理器部署在和硬件設備同網段的局域網中，它可以和硬件設備點對點直接通信，它通信的結果存儲在本地然后在周期性的進行上傳。它的好處很明顯，不需要設備支持服務器端（第一、二兩種方案都需要硬件設備支持）、可以在無網絡的環境工作，可以完全按照設備支持的方案進行開發，然后把需要的數據上傳到服務器端。看起來很ok，很完美，但是其實這種方案成本是非常非常高昂。
我在之前的工作中一直使用的是第一、第二兩種方案進行設計開發、這兩種方案看似成本很高，需要搭建單獨的通信服務，但是從宏觀和時間的角度來說其實很廉價。因為它只需要更新服務端的軟件就可以改造、調整優化、升級。不需要考慮客戶端，所有的設備只需要連接網絡、配置好通信ip和賬戶就完成了，不需要進行多余的操作。
現在我們使用的是第三種方案，中間層。之前我雖然知道這種方案、甚至因為它可以在無網絡的環境工作心動過，想親手設計實現一套。但是就目前的結果而言，我很慶幸我當初沒有去實現。並不是說這種方案很糟糕，相反它是非常優秀的方案，在理想狀態下，它的兼容性、和無網絡工作的特性是非常優秀的，只需要精心的去設計，嚴格的測試、緩慢的推廣。它應該是三種方案最優秀的方案。但是現實往往相反。
首先是安裝環境，我們向客戶推廣我們的系統時，客戶為了節省成本往往使用自己現有的計算機來安裝，但是他們的計算機五花八門、往往配置很低。
其次是管理維護。安裝中間軟件的計算機，應該保護好，即使關機也應該正常關機，而我遇到一個客戶，他的計算機是經常直接斷電的。計算機上安裝了數據庫，數據庫正在寫入數據的時候斷電會導致數據寫入損壞，導致數據庫崩潰、數據丟失。安裝短短十幾天數據庫崩潰四五次，每次崩潰都需要人工數個小時的時間恢復，更讓我難受的是，客戶一直不告訴我們真實情況，每次詢問都是計算機沒有關機，導致我一直無法找到數據庫崩潰的真實原因。
當然這只是個特例，但是這個特例卻能反饋出，第三種方案的應用難度，所以當我們選擇方案的時候，不能只從解決問題的方向去思考，而要從各個方面去考慮，作為一個系統架構師、系統設計者去選擇一個技術實施方案時必須三思而后行，如果不了解、和分析具體的應用不僅給自己挖了很多坑，也會為公司帶了很大的損失。