Re: [討論] 認證圖集中解碼
※ 引述《dpFish ()》之銘言：
: 大致歸納如下：
: 現在認證圖即使可能是用一定規則生成的，（前景 + 背景？）
: 但總數量太多，照原先建資料庫的方式的話
: 流量太大 server 會負荷不了；
: 我想其實一個認證碼的小圖不過幾 KB（？），（被 ban 看不到 ><）
: 比起幾個 MB 的「愛台灣.txt」應該算是還好的，
: 或許可請高手稍微仔細的估計一下流量，
: 如果覺得可行的話再進一步的實行。
: （而回傳的認證碼只有 3~5 個位元組應該是不成問題。）
我覺得資料庫會垮, 應該不是上傳的問題 (每支 client 上傳大概都只是幾筆而已).
相反的, 1支 client 下載資料庫會用到幾 mb 的流量, 再加上隔一陣子就要更新.
感覺上 server 就像一直被輪暴再輪暴一樣.
可是 dl 回去的 db, 以更新週期來算又只會用到幾十幾百筆, 非常不符合效益.
( Ian 大神大概是想考驗參賽國的程度, 用這種方法把難度提高一些. )
這讓我想起, anti-SPAM 界也有相同的問題, mail server black list db 的傳送.
也是傳多多, 用少少, 又要常更新. 後來這個問題被 realtime black list 技術所解決.
這兩個問題有一點類似, 厲害的大大們可以考慮將 key-value(digest-text) 的 mapping
擺到 DNS 的 RR 裡去, client 不用再 maintain 愈來愈吃人的資料庫, 查詢反應也不差.
server 也落得清鬆 ( DNS 本身就是一個超大的 cache system ). 只要專心接 case 就好.
不用煩惱資料怎麼同步到 client.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 139.175.160.250
→
06/24 02:25, , 1F
06/24 02:25, 1F
推
06/24 02:25, , 2F
06/24 02:25, 2F
→
06/24 02:25, , 3F
06/24 02:25, 3F
→
06/24 02:26, , 4F
06/24 02:26, 4F
→
06/24 02:27, , 5F
06/24 02:27, 5F
討論串 (同標題文章)