首先，在谈到结构该怎麽搞之前，先讨论一下资料该怎麽存放的问题... 基本上，资料有三项, 来源(图片特徵值), 结果(辨识结果), 加入时间 我看了一下爱台湾.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