引用:
lin8lin寫到:
IP一樣應該是指兩台電腦使用IP分享器對外的IP會一樣
但是對內還是有分192.168.0.1~192.168.0.2等等設定 嚴格來講是不一樣的
(...中略...)
3.
CPU、硬碟的速度：這方面也是桌上型的優勢
(後略...)
謝 in8lin 補充 192.168.0.1~192.168.0.2 Private IP 這一部份。(壞喵 想 initialdiablo 應該是指 Public IP 一樣，因為 Private IP 一樣應該會發覺區網會不正常。且 IP 分享器的 NAT 也會產生無法讓 eMule 取得 High ID 的現象。(Private IP 衝突了！)
引用:
XDR寫到:
兩台port不用錯開
子網段部分早就由IP分享器或啥東東處理好了
(後略...)
這點 壞喵 要反駁 XDR 的說法。
因為 當
騾子 A : 192.168.1.3 : TCP 4662 , UDP 4672 <-> NAT <-> Public IP : TCP 4662, UDP 4672
因為 eMule 連上網際網路的 Server 和 KAD 時，會回報自己的 TCP 4662, UDP 4672，這樣是可以取得 High ID。
但如果 ...
騾子 A : 192.168.1.3 : TCP 4662 , UDP 4672 <-> NAT <-> Public IP : TCP 4862, UDP 4872
因為 eMule 連上網際網路的 Server 和 KAD 時，仍會回報自己的 TCP 4662, UDP 4672，故這樣是會取得 Low ID。
(因為 eMule 回報給 P2P Server 的 Listen Port TCP 4662 根本和 Public IP 的真實 Listen Port TCP 4862 不一致，所以完全無法「聆聽」成功的。)
※ 會這樣是因為 eMule 的回報 Listen Port 的機制所致。若能改善當然是很好，可是似乎目前沒有 P2P 軟體能做到 (uTorrent 也是如此)，因為許多 P2P 軟體的 Listen Port 的位址是可「動態」改變的 ，若 Private IP Port 和 IP 分享器中 Public IP Port 不一致的話，P2P 軟體很難查覺這點並回報給 P2P 網域上的節點的。(Ex: Server or KAD 節點)
所以騾子的 Private IP 的 Port 和 NAT 後的 Public IP 的 Port 一定要一致，不然會取得 Low ID。
以上經驗都是 壞喵 「實驗」所得，若是 XDR 能提供
兩隻騾子 Private IP Port 都用 TCP 4662, UDP 4672，
但兩隻騾的 NAT 後，Public IP Port 一個設定成 TCP 4662, UDP, 4672 (應該可 High ID)，
另一個設定成 TCP 4862, UDP 4872，卻也能得到 High ID 的話？(應該會得到 Low ID 才對。)
那壞喵倒真想請教 XDR 是如何做到的？(也許 壞喵 功力不夠吧？貓 裝傻中...)
所以這就是 壞喵 說：
一. 兩隻騾的 Private IP Port 和 Public IP Port 必須錯開的原因。(為了都能得到 High ID)
二. 且「同一隻騾的 Private IP Port 和 Public IP Port 對應必須一致」 ，即
192.168.1.3 : TCP 4662,UDP 4672 的話，
Public 就必須也是 TCP 4662, UDP 4672 才能獲得 High ID。
(Public Port 改成 TCP 4862, UDP 4872 是得不到 High ID 的)
若同一 Public IP 的另一隻騾也要取得 High ID 的話。
192.168.1.4: TCP 4962,UDP 4972 的話，
Public 就必須也是 TCP 4962, UDP 4972 才能獲得 High ID。
這樣兩隻在 同一 Public IP (同一 IP 分享器) 的兩台電腦中各養了一隻騾，才能「同時都獲得 High ID」。
也歡迎高手吐槽指正錯誤，謝謝.... (互相切磋求進步，壞喵 會感謝您的！)
[badcat 在 2009-6-30 11:28 PM 作了最後編輯]
