本帖最後由 RadioNoise_1 於 2012-5-17 01:14 編輯
１.改進用戶來源交換的精度
有一種妨礙的方法就是通過用戶來源交換將一組組虛假的用戶（IP）交換出去
雖然零散的IP很難識別，但象*..1.1至..1.254，..2.1至.*.2.254這樣百幾、二百個連續IP，正常情況不是不可能，但是實在機會很低
這些IP會在用戶間通過交換相互傳播，生生不息，用戶的時間都花費在連接虛假的用戶（IP）之上
1.1. 一個IP就可以有六萬多個端口，對於相同IP多重端口，超過一定的端口數量的IP應當過濾
就算是使用隨機端口，在不斷的重啟用戶端，或同時開幾個用戶端，但這也總會有一個嘗試次數或數量吧
建議首先依靠改進用戶來源交換和cleanup機制，隨住時間自然淘汰已經失效的 IP:端口，以免怪錯好人
再對於這情況下還出現的超過一定的端口數量的IP（5個、10個、100個以上？），應當和之後所說的cleanup機制處理一樣，過濾阻止進行連接，但又不阻止連入
但隨住時間過去，當來源交換回報的該IP的端口數量跌回低於限制，即取消該IP的過濾處理
註：虛假用戶（IP）的意思是，這個IP並沒有在使用BT。
「相同IP多重端口過濾」應為可選功能，防止理想與現實不乎，有問題可以選擇不用
不排除虛假 IP/端口 會有花式的可能，例如單數、雙數，或每逢多少隔一等等，可能需要考慮加入智能分析的能力
例如可以在相同任務中，有開啓「虛假用戶（IP）過濾列表」的連接中的BC用戶之間，各自將經多次連接後100%確認連接失敗的 IP:端口 數據相互交換，如果相同任務連接中的全部BC用戶都連接不上，即放入虛假用戶（IP）過濾列表
但只要其中有一人可連上，應當即取消過濾，這是因為考慮到現實情況有防火牆等的問題，只有在100%的情況下才能夠被列入虛假用戶（IP）過濾列表
建議接收方只相信有實際數據傳輸過的用戶端的來源交換情報（BC用戶端以外）
建議傳送方只傳送「最近實際連接過」或「連接中」的用戶端給接收方，現在的交換方法就象滾雪球，越滾越多，但實際就沒有這麼多用戶
２.用戶數量的cleanup機制
如前所說，用戶數量越滾越多，但實際就沒有這麼多用戶
對虛假的一整列IP段的來源交換，進行「特別過濾」處理，BC應阻止對虛假用戶IP段進行連接，但卻又不阻止相關IP連接入來，這就不會怪錯好人
如果相關IP（用戶）是虛假的，不浪費時間嘗試連接，效率自然更高，但如果IP（用戶）是真的，它也自然會自己主動連接進來
虛假用戶（IP）過濾列表的維護
下載相同文件的BC用戶之間共享虛假用戶（IP）過濾列表的維護，每隔一定間距交換過濾列表的更新情況
例如在某一個BC用戶，有過濾列表中記錄的IP（用戶）主動連接進來，那這個連接進來的IP（用戶）就是真的，這時候就在過濾列表中刪除該IP過濾，並在下次過濾列表交換時將這情報更新出去
這裡要補充一下，虛假用戶（IP）過濾列表不應該用增量機制，因為這樣的話過去的錯誤就會一直被保留，應當以「最近」的來源交換數據為依據
如果「最近」回報的來源交換數據顯示，某些虛假IP（用戶）已不再出現，那就cleanup過濾列表，清除相關的IP記錄，保持過濾列表的實時性
cleanup機制
連接嘗試失敗達到一定次數後就從用戶列表中刪除和進行過濾（當相關 IP:端口 主動連接進來，即取消該 IP:端口 的過濾），防止總用戶數量象滾雪球一樣越滾越多
註：以上的列表數據、功能等，都只保持在任務運行中的狀況，如任務停止/再開、BC關閉/再開都會從新開始，數據不會保留，以免怪錯好人
「虛假用戶（IP）過濾列表共同維護」應為可選功能，防止理想與現實不乎，有問題可以選擇不用
３.一撃脫離的用戶數據收集行為
有些IP（用戶）的行為就是連上幾秒後不久就馬上脫離，隔段時間後又再一撃脫離，怎麼看也是在收集用戶數據的惡意用戶端
反吸血失敗在只要在被Ban的秒數之前先「自行脫離」，就可以輕易逃脫，無助解決一撃脫離的問題