首先，在談到結構該怎麼搞之前，先討論一下資料該怎麼存放的問題... 基本上，資料有三項, 來源(圖片特徵值), 結果(辨識結果), 加入時間 我看了一下愛台灣.txt 居然用64,16 Byte長度的資料@_@ 對結果做加密就算了, 來源值似乎也做過加密...? 基本上來源值用MD5或是CRC-64應該就足夠防止算出結果重複了 如果在換算之前多一道內部XOR的話，MD5/CRC的值就可以直接傳送了 我的建議的話...CRC-64長度為16Byte, 應該滿合適的 結果的話因為需要接收方做解密的關係 原本的加密方法應該就繼續使用下去 伺服器的儲存當然還是SQL比較好 用來源做Primary, 加入時間做Index 每一筆的資料長度大約是32Byte 然後以每x筆為單位做一個升級包 由於資料長度固定, 逗號跟換行其實都不需要的資訊 倒是升級包需要做一個整個資料的效驗碼，免得資料傳錯了... 伺服器的工作則分為兩個部份 1.接受客戶端的更新提供 2.接受版本更新請求 當客戶端啟動的時候 會向伺服器提供自身當前版本 並由伺服器方面提供一直到最新版本為止的升級包 為了簡化封包複雜性 這兩項工作應該由不同的服務Port來處理 而且最好是用UDP方式 甚至其實也可以用不同的主機來處理 一台機器只儲存升級包，另一台才處理資料 之後，當客戶端收到新的來源時，並不立即請求更新 除非系統已經超過一段時間接收到新來源且一直沒有提交更新 (也就是當使用者不在的時間)才用啟動模式更新版本 另一方面，當客戶端有提供新的結果時 會向伺服器提交包含自身當前版本及最新的來源&結果 伺服器就會更新資料庫，並且檢查新的升級包是否已經完成 如果已經完成則回傳 ============== 再來，就是偽造的請求跟偽造的結果這兩個問題 偽造的版本更新請求會讓伺服器負載過度 我是不知道是不是有人會這樣搞啦 不過版本更新請求還是應該加一點驗證碼才是... 偽造的結果可以利用重複檢核或是信任的支援者來處理 重複檢核就是儲存同一個來源的結果重複率跟來源主機 也就是假定多數的使用者提供的是正確得結果 不過萬一遇到DDOS一樣無法 或者就是在新增一種封包請求 就是「這一筆來源-結果對應是錯的」這樣的信息 但是其實一樣擋不住DDOS 信任的支援者是比較安全的方式 也就是只讓特定的一些人提供更新資料 其他人只能請求新的升級包 這種的好處是不怕被假結果攻擊... 不過要找信任的支援者很麻煩的, 得主動去找 或者呢，就是讓整個資料的編碼複雜性增加 讓來源&結果的編碼互相掛勾 增加偽造結果的複雜性 這方面的方法我還沒想到.... --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.204.46