Re: [請益] msn傳檔問題
※ 引述《z2o (有空再想)》之銘言：
: 標題: [請益] msn傳檔問題
: 時間: Thu Jul 12 23:32:09 2007
:
: 救我個人的了解
: msn應該是透過登入msn server之後再與其他用戶通 話 溝通
:
: 那如果傳檔呢
: 也是透過server給嗎
: 感覺繞了一圈ㄟ??(先給server,在給我想要傳送的對象)
先前看到這個問題是有想要回，不過因為我也不知道確切的答案，所以就沒有動手。
其實要知道答案也不困難，只要用 ethereal trace 一下封包就知道了。
只不過一來我很少用 MSN ，二來我最近有點忙 (我的程式 bug 好多)，
所以就沒有動手去做。不過我可以先回概念性的答案來說明兩種方法的優缺點。
登入 msn server 的部份主要是要保有一份正確的使用者清單，
這份清單裡面應該要有使用者的名稱(e-mail)和使用者所在的位址。
不管實際通話或傳檔是否通過 server 來轉送，這兩個資訊都是必要的。
如果是透過 server 來轉送，那麼 MSN server 與每一個 client 之間，
都必須要保有某種形式的連線，最簡單的就是維持一個 TCP connection ，
這樣要傳東西的時候就直接送，斷線也可以很快地知道。
由 client 向 server 發出一個 TCP connection ，
通常不會被防火牆阻擋，因此也較沒有設定上的困難。
如果不透過 server 來轉送，那麼 MSN server 至少要有 client 的 IP 和 port ，
當 A 試圖要與 B 溝通的時候，由 A 向 server 要求 B 的 IP 和 port ，
再對 B 的 IP 和 port 建立一個連線，由 A 直接向 B 連線來溝通。
這樣的作法必須要 B 允許該 port 的封包通過，通常需要另外設定防火牆。
另外這樣的作法無法穿透 NAT ，如果 B 在 IP 分享器後面則可能收不到封包。
透過 server 轉傳的好處是穩定，因為只要雙方到 server 的 connection 都在，
就一定有辦法把封包送到對方的手上。兩個 client 都不需要有額外的設定，
只要 server 端的 port 是打開的，連線就能夠建立起來。
但是缺點是 server 的頻寬和處理能力有限，當很多人同時使用或資料量很大時，
速度就變得很慢，甚至可能會發生因為 buffer 滿了訊息就不見或很久才大的狀況。
直接連線的好處是快，而且很有效率。也不容易造成在 server 端的效能瓶頸。
但缺點是沒有 server 的認證， p2p 的連線時身份較易被偽造，
另一方面這樣的連線無法穿透 NAT (尤其是如果兩邊都在 NAT 後面，根本連不起來)，
很多時候需要額外的設定，相當不方便。如果遇到有防火牆或 NAT 的情況，
就必須要另外找一個 peer (不一定要是 server) 來轉傳封包。
雖然我不知道 MSN 是怎麼運作的，不過 Skype 是透過直接連線，不用 server 轉傳，
如果雙方都在 NAT 或防火牆後面，它會找某一台效能不錯又沒有防火牆或 NAT 擋的，
透過第三方的電腦來作轉傳，因此你如果用 Skype 又大門開開，就可能被利用頻寬。
詳細的情況可能有點離題，如果有人有興趣再詳加討論吧。 :)
: --
: 感謝回答
:
: --
: ※ 發信站: 批踢踢實業坊(ptt.cc)
: ◆ From: 59.116.182.81
: 推 alpe:nope 07/13 00:57
: → usera:蠻想噓的 這種問題怎麼跑來這裡問 07/13 11:10
這問題的形式雖然不太符合，但如果改成問:
為什麼要透過 server? 或 為什麼不透過 server? 可能就還 ok :)
--
活著的目的是為主活 然後為主死
死亡的目的是為主死 然後為主活
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 60.248.178.70
推
07/13 21:26, , 1F
07/13 21:26, 1F
→
07/13 21:27, , 2F
07/13 21:27, 2F
→
07/13 21:27, , 3F
07/13 21:27, 3F
推
07/13 23:27, , 4F
07/13 23:27, 4F
→
07/14 00:59, , 5F
07/14 00:59, 5F
推
07/14 09:13, , 6F
07/14 09:13, 6F
推
07/31 19:47, , 7F
07/31 19:47, 7F
討論串 (同標題文章)