現有的股標交易傳輸系統, 多數是在DOS 下工作的。系統設計是單任務工作型, 一般是把傳輸 和顯示分開實現。這種設計的缺點一般有: 浪費系統 資源; 界面不友好; 操作不方便。 考慮和以前DOS版本的兼容以及開發的速度, 行情 顯示和行情傳輸兩模組之間採用檔案接口方式。即傳 輸模組把接收到的數據按dbf 檔案格式存放。而顯示 部分則直接讀取dbf 檔案。這樣接口方式簡單。便於 分組開發設計。傳輸模組則是在Windows 下通過串 行口對Modem 進行操作。Window s 311 提供了一組 通訊函數(見附錄A ) , 利用這些函式以及Window s的多任務機制, 可以方便地設計一個具有實時回響和 多任務能力的傳輸系統。 MODEM 有一個標準的A T 命令集。在命令 (COMMAND)狀態時, 給MODEM 發一個A T 命令, 執行完畢後,MODEM 要返回一個狀態碼, 表示該命 令的執行情況。也就是說, 在給MODEM 發命令和 MODEM 返回狀態碼這兩個事件之間是有時間延遲 的。為了正確地接收到MODEM 的狀態返回碼, 一般 的DOS 應用程式是採用查詢或中斷的髮式讀MODEM。而在Windows 下, 利用其多任務機制和Win2dows 的通訊函式可以隨時給MODEM 發命令, 而且 只在MODEM 的狀態碼返回之後, 應用程式才去讀 返回碼, 不必循環等待, 這樣就實現了系統的多任務 機制。
當MODEM 在數據(DATA )狀態(即MODEM 正通過電話線路傳輸數據)時, 也可以按類似的原理 來操作。MODEM 傳輸數據都有規定的協定, 為了安 全性考慮, 一般要進行數據校驗。採取的方法一般是 傳送方傳送一幀數據時, 在其中加入校驗碼, 接收方 收到數據後, 按預先規定的算法對接收到的數據進行 校驗。若結果和傳送過來的檢驗碼相符, 則數據正確; 否則, 數據在傳輸過程中出現錯誤。校驗完畢之後, 接 收方給傳送方返回一個狀態碼, 表明接收到數據的正 確與否。而傳送方則依據這個狀態碼來決定下一步的 工作。 同命令狀態一樣, 數據狀態時的傳送方在送完數 據和接收到返回碼兩事件之間, 也是有時間延遲的。 (一般規定為 3 秒鐘, 超過 3 秒鐘則認為線路出錯)。 所以傳送方在傳送完一幀數據後, 就出讓Windows 的系統控制權, 當有狀態碼返回時, 應用程式再去讀 返回碼並作進一步的處理。這樣就可以對通訊事件實時回響(有事件時立即回響) , 並且具備多任務能力 (事件處理完畢立即出讓系統控制權)。這也是我們這 個股票交易傳輸系統的設計思想。
2 傳輸數據幀結構
由於本系統對數據安全性要求較高, 而且數據量 不是很大, 所以選用高級數據鏈路控制規程(HDLC) 的校驗方法和幀結
3 傳輸過程的描述
傳輸過程首先起始於MODEM 的撥號, 當設好 波特率等一系列參數後(作為外部參數設定) , 起動系 統時, 先引導初始化模組, 該模組根據系統參數給 MODEM 一條條發命令。每一條命令執行成功後, 就 取下一條命令執行, 直到執行完畢。
本系統的傳輸共有 3 種數據類型: Ⅰ 股票行情 的檔案傳送(伺服器傳送)。Ⅱ 委託報盤的記錄傳送 (本地買賣股票後由本地系統傳送)。Ⅲ 成交回報的 記錄傳送(股票買賣情況的回送, 由本地申請, 伺服器 傳送)。
每種數據傳輸都是由本地機發起的, 它向伺服器 傳送一個申請幀(不同數據類型, 代碼不同)伺服器根 據情況做出回應。若收到同意傳送的幀, 則本地機回 送一個幀已收到的信息, 然後由傳送方開始傳送數 據。接收方接收數據並檢驗正確, 則回送一個接收正 確幀。傳送方則繼續傳送, 錯誤則回送一個接收錯誤 幀, 由傳送方重發剛才的數據幀(若一幀數據 3 次發 送後仍然不正確, 則認為出現致命錯誤。系統中止當 前工作, 重新啟動) , 這樣直到數據傳送完畢。此時發 送方傳送一個數據結束幀。在收到回應後, 結束雙方 的收發工作。
