基于TCP協議的多媒體教室遠程管理系統的設計

張波

摘要：本文主要討論了多媒體教室遠程管理系統的軟件設計部分。下位機軟件模塊包括主程序、射頻讀卡子程序和網絡通信子程序，網絡通信子程序模塊重點闡述了TCP協議驅動層的基本方法和TCP連接建立的三次握手過程；上位機軟件模塊主要是監控主程序，重點闡述消息包的處理過程；數據接口通過一卡通和教務的web服務接口完成數據同步。最后，總結了系統的設計意義。

Abstract： This article mainly discusses the software design of multimedia classroom remote management system. The software cludes lower machine contains main program， RFID subroutine and network communications subroutine. The network communications subroutine focuses on basic methods of TCP protocol driver layer and the process of TCP's three handshake； the main software of upper monitor is monitor master program. The article particularly explains processing procedure of the message packets； the data interfaces complete data synchronization through the web services provided by campus card system and educational administration system. Finally， the article concludes the system's design significance.

關鍵詞：多媒體教室；上位機；下位機；TCP協議；Web服務

Key words： multimedia classroom；upper monitor；lower machine；TCP protocol；Web services

中圖分類號：G434 文獻標識碼：A 文章編號：1006-4311（2016）05-0195-03

0 引言

隨著多媒體教學的日益普及，各個學校的多媒體教室數量在迅速增長。在現有管理人員不變的情況下，如何更加高效的管理多媒體教學設備成為學校迫切需要解決的問題。本論文從技術的角度給出一種遠程監控管理多媒體教室設備的方案。

系統硬件是基于Silabs公司的C8051F020單片機進行開發的，外圍電路主要分為四個模塊：設備控制模塊、射頻讀卡模塊、網絡通信模塊和時鐘發生模塊。射頻讀卡模塊采用Philips公司的MFRC522射頻讀卡芯片，網絡通信模塊采用Silabs公司的CP2200以太網控制器。硬件接線圖在這里不是重點，本文主要討論系統上位機和下位機軟件設計部分。

1 下位機軟件設計

1.1 系統主程序設計

系統主程序如圖1所示。C8051F020單片機（以下簡稱下位機）在沒有通電的情況下，服務器（以下簡稱上位機）組態軟件顯示中控為離線狀態。當下位機上電復位完成初始化以后，網絡模塊會以TCP協議自動連接上位機端口，上位機組態軟件顯示中控為在線狀態。在線狀態下，下位機會循環判斷是否有IC卡在識別區，如果讀得卡號則推送給上位機進行驗證，如果上位機一直沒有回應（超過3秒）則通過查詢本地flash存儲進行驗證。下位機會一直監聽上位機的控制指令并完成對周邊多媒體設備的控制。下位機每15秒種向上位機發送保持在線狀態的心跳包，同時每1小時發送一次下位機flash存儲數據表更新的請求包以盡量保持和一卡通賬號數據及教務課表數據一致。下位機根據設備控制模塊鍵盤電路的中斷請求，讀取鍵值并執行。

1.2 射頻讀卡子程序設計

射頻讀卡子程序如圖2所示。MFRC522初始化完成之后，通過尋卡-防沖撞-選卡三步循環讀物理卡號，然后將讀取的物理卡號提交至服務器進行身份驗證。如果在3秒內收到服務器返回的通過驗證命令，系統就直接打開電源輸出，否則就認為是網絡故障或離線狀態，先從時鐘芯片讀取當前日期時間段，然后查詢下位機本地flash存儲進行工號驗證。這樣設計既保證網絡在線的情況下教師能夠完成刷卡身份驗證，又保證了網絡故障或離線的情況下教師同樣可以正常使用多媒體設備。

1.3 網絡通信子程序設計

網絡通信模塊軟件主要包括模塊初始化程序、CP2200驅動程序以及嵌入式TCP/IP協議棧三部分，其中CP2200驅動程序主要完成接收網絡數據以及向網絡發送數據的工作。由于嵌入式Internet系統軟硬件資源有限并且通常功能需求較少，因此在構造嵌入式TCP/IP協議棧的時候可以對TCP/IP協議進行裁剪。本系統設計的嵌入式TCP/IP協議棧只選取了三項協議：ARP、IP和TCP，以下將重點闡述下位機的TCP模塊。

TCP（傳輸控制協議）是建立在IP協議之上的運輸層協議。由于加入端口（port）的功能，實現了傳輸通道的復用和分用功能。TCP數據報首部為20～60字節，是一種面向連接的，能提供可靠數據傳輸的服務。TCP協議功能主要由TCP初始化函數init_tcp（）、TCP保活函數tcp_inactivity（）、TCP發送函數tcp_send（）、TCP接收函數tcp_rcve（）和TCP重傳函數tcp_retransmit（）實現。

在和上位機建立tcp連接時，需要進行三次握手才能完成，如圖3所示。第一次握手下位機發送請求包，之后下位機將收到上位機的應答兼請求包并回發應答包開始第二次握手，上位機收到下位機的應答包之后再回發應答包進行第三次握手，此后雙方的tcp連接建立完成。在連接已經建立的狀態下，下位機在收到一個tcp包時，先將對應連接對象的上位機請求號增加接收數據的長度，并且將下位機請求號和上位機應答號都置為tcp包應答號，然后再發應答包。上位機的應答號必須和下位機的請求號保持一致，如果應答號小于請求號則表明下位機沒有收到上位機的應答包，下位機重發緩存的數據包，如果重發兩次仍然是應答號小于請求號則直接關閉該連接。如果是應答號大于請求號則直接關閉該連接。重發的管理過程是通過tcp_retransmit（）函數實現的。Tcp連接的關閉是通過四次揮手的過程完成的，如圖四所示，這里就不贅述具體過程了。

本系統之所以選擇tcp協議而不是網絡開銷相對較低的udp協議，主要是因為tcp協議能夠很容易的跨越各種網關和防火墻進行通信并且穩定性和可靠性更好，如果考慮后期再加入遠程系統維護功能模塊則無疑選用tcp協議更加合適。至于增加的一點網絡開銷，在校園網網絡設備端口和帶寬向千兆位甚至更高位發展的今天，完全可以忽略掉了。

2 上位機軟件設計

2.1 監控主程序的設計

監控主程序如圖5所示，主窗口加載以后便創建用于服務端偵聽的主socket、處理接入的子線程和管理子線程。其中處理接入的子線程負責客戶端socket的接入處理，當有遠端連接時，首先創建新的連接對象和新的連接socket，并進行關聯，然后創建新的連接子線程并進行關聯，最后將連接對象加入客戶端集合對象中；管理子線程主要負責離線連接對象的清理、自動恢復和刪除選中的客戶端socket、讀取后臺數據庫狀態并更新樹形列表和查詢數據庫顯示當前教室狀態。它首先循環遍歷客戶端集合對象結構中的每一個連接對象，然后將超時的對象剔除，超時的判斷根據是連接對象的刷新時間與當前時間間隔超過20秒，剔除之前應關閉對應的遠端socket和連接子線程并且更改其狀態為離線，之后將后臺數據庫教室節點中控狀態設置為離線。下面的讀取后臺數據庫狀態并更新樹形列表就根據所遍歷節點的ip地址查詢數據庫中中控的狀態值，根據中控狀態值，為0設置節點關閉，為1設置節點打開，為2設置離線并從客戶端集合結構中剔除。最后一步，查詢數據庫顯示當前教室狀態，就是根據當前選擇教室號從數據庫中查詢中控狀態值、投影機狀態值、主機狀態值和投影燈泡時間，然后根據這些值去更新右側下方的標簽。這里需要注意的是為了避免子線程間使用同一數據連接對象對數據庫操作發生意外沖突，建議每個子線程用不同的數據庫連接對象操作數據庫，單個方法過程的數據操作只需要打開關閉數據庫一次即可，這樣可以提升數據庫讀寫效率。

監控程序處理各種類型的消息包是由單獨啟動一個連接子線程進行的，當收到有效數據包時首先記錄時間戳，后面管理子線程會根據這個時間戳判斷下位機是否離線。然后判斷是否刷卡消息包，如果是則根據物理卡號查詢一卡通表工號，再根據當前時間段查詢教室課表工號，將這兩個工號比較，如果相同則向下位機返回打開命令并更新后臺教室狀態數據表為打開，如果不同就不做操作直接返回；如果不是刷卡消息包就判斷是否激活消息包，如果是激活消息并且是第一次激活則修改后臺教室狀態為關閉狀態；如果既不是刷卡消息又不是激活消息則判斷是否為響應消息包，如果是響應消息包則根據響應的操作修改后臺教室狀態數據表；如果以上都不是就判斷是否為數據更新請求消息包，如果是則查詢對應教室號的課表數據和一卡通數據然后發送給下位機。

2.2 數據接口的設計

系統數據接口包括一卡通接口和教務接口兩部分。一卡通接口是調用一卡通的web service接口，從一卡通原始數據表抽取工號、卡號和姓名三個字段，然后經過數據格式轉換存儲到本地的數據表yikatong當中供使用；教務接口是調用教務系統的web service接口，從教務系統原始數據表抽取課程名稱、教師姓名、上課時間（含周次和節次，分號間隔）、上課地點（和上課時間對應，分號間隔）四個字段，然后經過格式轉換存儲到本地的數據表jiaowu中供使用。

數據接口處理當中的難點在于數據結構和格式的轉換。例如原始一卡通表中的卡號為十進制的字符串類型varchar（10），可變長度，最長為10，而系統需要的是4個字節十六進制表示的卡號，可以先將獲取的字符串轉換成32位無符號整形，然后將32位無符號整形轉換成字節數組，最后將字節數組作為參數插入數據庫卡號字段。再例如原始一卡通表中的工號是可變長度字符串類型varchar（10），而系統需要的工號是固定長度10 char（10），這里只要將原始工號長度不滿10的左邊填充0就可以了。而教務表的整個數據組織結構都和系統不一樣，需要按照工號、教室號、時間段、周次組織數據，這樣就先要從一卡通根據姓名查得工號，然后將上課時間，上課地點按照分號對應拆解開，在上課時間里面再按周次拆解，經過層層循環拆解最終形成系統的數據結構。上課時間段目前是按照每天5段（1-2，3-4，5-6，7-8，9-10），每周7天一個循環，也就是一共35段計算，周次以實際教學計劃為準。

為了保證數據接口的安全調用，所有的web service調用必須集成網站的windows身份驗證，只有指定的開發者才能夠調用，使用NetworkCredential類便可以安全調用集成windows身份驗證的web service服務。數據接口的調用方式除了以手動點擊按鈕的方式啟動外，也可以定時調用，為了不影響校園網絡的運行可以在夜間進行大數據量的同步，教務臨時排課盡量提前一天完成，這樣夜間完成同步第二天便是最新的同步數據。

3 結束語

通過本系統，一方面能夠讓管理人員在控制室遠程監控和管理教室設備，對于發生故障的設備能夠在第一時間給予維修，提高了設備的運行效率，減少了設備維護人員的工作量。據統計，使用該管理系統以后，設備維修的平均響應時間縮短75%，教室設備的平均故障率降低53%，設備管理人員的維護工作量減少了68%，師生對于多媒體教室的使用滿意度大幅度提升。另一方面教師不用領取專門的講臺門禁卡，可以直接用校園卡刷卡使用多媒體教室，更加方便而且利于統一管理。

參考文獻：

[1]李慶.基于嵌入式TCP/IP技術的網絡型多媒體中控器設計[J].陜西科技大學學報，2010.

[2]位永輝，劉篤仁.基于MF RC500的非接觸式IC卡讀寫器設計[J].電子元器件應用，2007.

[3]肖俊武，許愛秋，魯俊偉.利用C8051F020的SMBus實現時鐘/日歷芯片讀取[J].電子元器件應用，2006.