C#-JudgeSystem判題系統-判題系統

運行環境: vs2013

框架: .net4.5

上一次實驗已經完成了判題核心的封裝，接下來就是經過服務器後臺調用判題系統對客戶端傳來的數據進行判斷

根據前面的一些測試咱們創建新的解決方案來實現完整的判題系統

首先第一步咱們先肯定客戶端和服務器的交互流程

客戶端的數據有三個：源代碼，輸入，輸出

這時候到底怎麼傳到服務器的，有兩個方法，一個是一次性傳輸，一個是分三次傳輸

一次性傳輸的話就要面臨怎麼切割這三種數據，必須定義一個分割符，並且數據也要面臨轉義的問題，到了服務器也須要進行解譯，這樣會消耗必定的資源

但到底這三個數據是否是必定要一次性傳輸呢？其實並不用，由於這三個數據做用於不一樣階段而且能夠單獨分割開來，因此分三次傳輸實際上是能夠的，而且每一個階段均可以根據回傳來判斷判題的狀態，出現錯誤是能夠減小後面兩次的傳輸，節省必定的寬帶與內存

server              cilent

                        send:源代碼

read:源代碼

compile:源代碼

send:編譯結果

                        read:編譯狀況

                        若是成功

                        send:輸入

read:輸入

run:輸入

send:運行狀況

                         read:運行狀況

                         若是程序成功運行結束未超時

                        send:輸出

read:輸出

比較輸出

send:結果

                         read:結果

close                 close

作好流程設計後開始編碼程序

因爲把輸入輸出分離，因此類庫接口須要改變適配，類庫改變的成本較低，因此不採用改變調用

分割實現

第一步服務器讀取源代碼

編譯，根據返回值來發送結果

若是編譯經過就繼續向客戶端讀取測試輸入

考慮到部分程序不須要輸入因此接收到\r\n則看成無輸入

因此不容許程序只那\r\n來做爲測試輸入，事實上也沒什麼意義這樣的輸入

雖然能夠再增長一次交互來肯定程序是否提供無輸入測試，但這裏並無作這個操做

若是能拿到結果不超時，則向客戶端讀取結果進行匹配

下面創建一個測試用的客戶端項目

客戶端三次大循環往服務器發送消息

運行服務器，監聽8080端口

而後打開客戶端進行鏈接

而後打開客戶端進行鏈接

設置了30秒的超時

過了30秒客戶端無發送數據的話，會主動關閉鏈接

再次啓動新的客戶端測試

語法錯誤的測試，會返回客戶端1，表明false

沒有語法錯誤編譯經過的則返回0

測試第一部分經過則測試第二部分，輸入部分，源程序應該輸入兩個數字空格，輸出兩個數字的和，但測試中我只輸入一個數字，5秒後程序還沒結束則返回false，服務器端能夠看出緣由是超時

啓動失敗比較慢測試出來，還有一種多是正常非正常退出

雖然輸入是正確的，可是程序退出值不爲0，看成錯誤處理，返回false

最後測試正確輸出獲得結果

雖然輸入正確也能獲得結果了，可是不匹配，則返回false

測試1+3=4能夠經過，最後返回true，證實編譯經過且結果正確

到此爲止就完成了服務器程序的大部分功能了，並且異常機制與超時機制也能夠保證服務器的運行

而後爲了保證服務器的併發編譯穩定性，測試程序將改爲自動多線程併發執行判斷結果是否經過

爲了能遍歷併發各類各樣的狀況，我把三個步驟的正確與錯誤作法寫出用來作組合處理

第一步，錯誤是少一個；分號

第二步提供一下錯誤的輸入

第三部提供錯誤的結果

check返回值，讀取服務器的返回，0爲true，1爲false，每進行一步操做都要check一次看是否能匹配那次操做的返回值，不對應則爲一次bug

線程函數已三個數字啓動，作成字符串的形式

000表明三步爲true

111表明第一步錯誤

011表明第二步錯誤

001表明第三步錯誤

啓動線程遍歷四種狀況，每10次啓動線程讀取一次bug次數

併發間隔是500ms

啓動線程遍歷四種狀況，每10次啓動線程讀取一次bug次數

併發間隔是500ms

放置啓動700次線程，理論上大部分線程都完成操做，沒有發現任何的bug

後來將併發速度提高到100ms

程序運行很是快，cpu佔用也到了80%左右

短期運行下是沒有任何的錯誤，服務器和客戶端都沒有崩潰

在進行上千次運算後

任務管理器中並無發現遊離的進程

在測試路徑下發現大量的編譯程序

該測試證實，服務器系統是穩健的，高併發的，而且能提供準確返回值的系統

固然此次測試是在可靠的傳輸環境下實現的，而在不可靠環境下或者網絡環境較差的狀況下，服務器只能依賴於自身的超時檢測，在30秒內客戶端無消息則關閉鏈接

在完善服務器的狀況下，咱們繼續實現客戶端的GUI化

GUI部分簡單複用一下原來第一個實驗的代碼，但須要增長輸入輸出框

簡單修改一下

裏面一下控件有必要的寫上變量名

所幸的是textbox控件自帶換行的功能，這個能夠省去相似控制檯的添加換行符的複雜問題，只須要將原來的控制檯的程序代碼複製一下，須要的數據改爲從gui獲取

點擊ui上面的判題按鈕會觸發judge函數

完成後咱們測試一下運行的效果

打開程序

若是在沒有源代碼和輸出的內容條件下，判題是不容許的

無輸入的判題(任意輸入)

服務器關閉的狀況下

會顯示服務器鏈接錯誤

源代碼少一個分號，顯示編譯錯誤

不進行正確輸入，服務器會顯示超時處理，客戶端會顯示錯誤的輸入

輸入正確則判斷結果，結果不正確則輸出錯誤的結果

結果正確，天然進入接受狀態

對此已經完成客戶端的基本功能，固然再錯誤的輸入或者在算法複雜度較高的運算中，服務器未可以作出及時的相應，這時候就要作線程處理能夠避免程序在等待過程當中表現的卡死現象，暫時不去實現這是優化性的功能，到此整個實驗已經進行完畢

經過最後一個綜合實驗，整合每一個實驗的內容，完善服務器功能與客戶端的使用，在實驗過程當中，對於服務器的穩健性等作了更深層的探索，而客戶端部分還有一些線程級別的優化並無進行，有待實現，從開始的設計到各個部分的調整，也體會到知識綜合應用的重要性，在這一次實驗中並無過多新知識的掌握，更重要的是接口與測試部分的實現