| #5 : 2004-6-12 07:12 PM
只看本作者
|
 送花
(0)
 送出中...
|
|
|
預留多少並不是固定的, 得看傳輸軟體的特性才能決定
一般而言, 回應收到資料的封包都很小
但是, 每個封包有多大, 則是一個大問題
例如, 假設每個封包20K, 100K 的速度只需要5 個回應封包, 假設每次回應32 bytes, 只需要0.16K 的回應而已; 如果每個封包只有1K, 那100K 速度需要100個回應, 那回應頻寬需要高達3.2K
以驢子而言, 在512/64 的條件時, 上傳為6.3K 左右, 如果上傳設到5K, 其實下載會剛好跑不到20K, 但是, 如果是1M/128K 的條件時, 兩者都是加倍, 但是, 設定10K, 下載卻可以跑超過40K, 仔細分析其原因, 具有以下兩種可能性: (我沒去看細節程式碼, 只是可能性!!!)
1. 驢子每次傳遞的封包並沒有固定, 他有個上下限的range, 在range 內, 上傳越大, 效率越高
2. P2P 軟體除了上下傳資料, 還需要跟server 取得聯繫, 或者overnet 需要跟其他client 取得聯繫, 這些, 都是額外的資料在傳遞, 他需要一些額外的上下傳頻寬, 而這份頻寬是固定的
BT 在早期用Python 語言所寫的client 中, 都一律採用大封包結構, 例如: PTC/Shadow 這兩個版本, 每次傳輸固定約16K or 20K, 所以, 當上傳頻寬不大的情形下跑BT, 會發現, 每隔幾秒下載會完全停頓一次, 例如, 假設上傳設定3K, 線路是512/64 (上傳約6.3K), 則每7 秒鐘當中, 約有2-3秒的時間下載完全停頓, 因為20K 的資料需要3 秒鐘才能全部傳輸出去, 這三秒鐘, 所有回應下載的封包都出不去, 都在排隊等待傳輸. 後來用Java 所寫的Azurues 則把這個作法改變掉, 變成封包大小會根據上傳調節.
Azurues 跟ED client 都能夠讓上傳控制到使用者所規定的速度內, 在作法上可以是可調整大小的封包, 或者利用multi-thread 準確的控制傳輸速度, 也就是, 讓一個大封包以極慢的速度傳出. 實際上他們怎樣做, 我並沒有去看 ^^"
呵呵... 突然想到... 有人研究過ED 封包結構, 或者他們兩個可以來解釋除了上下傳以外的額外傳輸部份, 還有封包是變動大小還是精確控制傳輸速度.
Acute.
[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]
|
