個人積分：2分
文章編號：29033081
個人積分：2747分
文章編號：29033202
chais wrote:
可是你卻說它是「非P2P」又說它是「底定了P2P目前的架構」
應該是表達不夠正確導致您有所誤解，我說明一下
claus950 wrote:
"BT是由於ADSL頻寬不對稱的環境下而發揚光大的產物"
而非P2P!!
這裡的P2P是要拿來替換雙引號裡的BT，而不是指"BT非P2P"
另外"BT是P2P的一種實作"這點沒有任何問題
但問題是為什麼會出現這樣的實作方法??
chais wrote:
架設一個Web/FTP Server，以 http、ftp 傳輸協定來分享資源，並達成你所謂的「1對1的P2P」、「減少連線數」此時有1000位使用者(假設各自擁有1Gbps/1Gbps對稱頻寬)欲連線進來取得你分享的BD資源，一張BD以30GB來計算伺服器頻寬的流量為30GB*1000=30000GB、連線數為1000、每位使用者耗時30GB*1024=30720MB/100MB約5min但是有想過伺服器需要多大的上傳頻寬才夠用，如果使用者人數再爆增呢 ?
使用者有了高速的對稱頻寬，真的就解決分享問題了嗎 ?
您的算法太簡化，簡化到甚至算不上P2P，因為P2P本來就不是1000人同時只連上1台主機
以你提供的假設環境來說好了，1G/1G的環境，30GB的資源
1G的流量大約是100MB/s，30720/100=約5.12分鐘(其實我不懂，為何你的MB數是用1024去精算，但是Mb轉MB時又是使用除以10的粗略算法，一般不是精準就是粗略，放在一起用還真是...怪怪的)
今天BT的方法是把檔案切成1000分，平均分給各個需求者(其實也不是一定平均，但為求最佳化，就算他是平均的好了)，然後各個使用者分別跟其他使用者取得未完成的項目
OK!計算開始：
30720/1000=30.72MB(這是每個人分到的檔案大小)
1000/1000=1Mb=100KB/s(這是每人分到的平均流量)
30.72MB*1024/100KB=31457.28/100=314.5728秒
約等於5.24分鐘(這是每個人從我這裡把自己該載的都載完的時間)
但是基於下載時同樣可以分享的基準上，其實這個時間大約也是1000人都完成下載的時間(多麼驚人!!)
但是呢，今天在對稱頻寬的加持下，ezpeer能有怎樣的表現呢
以1對1的P2P來說，A給B的同時，B也可以給C，C可以給D，D可以給E，E可以給F
以此邏輯來說，約莫也是5分多鐘可以完成1000人份的資料散布(有比較慢嗎??)
而且可以避免掉可怕的連線數問題
所以對等頻寬下的BT會比較厲害嗎??
所以我才說"BT本來就是為了因應ADSL這種上下不對等頻寬的一種技術，要是頻寬對等了，鬼才要用BT咧!!"
個人積分：7分
文章編號：29042194
Lyan0913 wrote:
呀呀年輕人，你真的是睡不著，被氣到了是不？不要吐血啊！哈哈！4點多寫了一篇，將近7點又寫了一篇，篇篇都是落落長，你也不嫌累，年輕人就是年輕人，有體力也很氣盛，Good！
你貼我的那二篇我都忘了，回頭看了一下都是去年的，到今天都快是一年前的東西了，就算網路位址有部分一樣也不能說明什麼，中華電信每分鐘都不知道發出多少網路位址給使用者，世界上巧合的事情很多的，你要這樣聯想也無所謂，只要有人噹你你就會去翻這些東西，真是好勝然心胸也不夠大，我只能說老女人我就是我，沒有很多時間來理你，你愛怎麼說就怎麼說，你就在這裡慢慢的嘔吧！但不要氣死呀！
你還不知道我回覆那篇文用意嗎，不過只是想把你這樣的偷機暗爽心態呈現出來而已
你還真以為我很生氣、很嘔嗎 ?
很可惜耶~~ 你可能要很失望了....
我完全沒有對這回事做出什麼情緒化的反應，只是基於一個直覺去Google罷了
然後弄了一個陷阱等你跳進去
早料到你會有什麼回應，我一點都不意外
你的回覆只是顯得你心虛而已
若真光明正大，想想文章應該是怎麼表達的
而不是抓了一個你認為的把柄，在那邊自我高潮、暗爽
你這樣的心態完全表露出來
很謝謝你的配合 XDD
個人積分：7分
文章編號：29042462
claus950 wrote:
這裡的P2P是要拿來替換雙引號裡的BT，而不是指"BT非P2P"
另外"BT是P2P的一種實作"這點沒有任何問題
但問題是為什麼會出現這樣的實作方法??
看完之後不太想再回覆
因為我想我們彼此有個點有誤會
不過這不影響下面要討論的重點
所以這部分就略過吧 XDD
至於為什麼會出現這樣的實作方法，請自行研究
該討論到的部分都有出現過了
claus950 wrote:
其實我不懂，為何你的MB數是用1024去精算，但是Mb轉MB時又是使用除以10的粗略算法，一般不是精準就是粗略，放在一起用還真是...怪怪的
其實我是寫到有點小懶不想寫啦，看懂要傳達的意思就行 XDD
確實我沒有做到精確，不過我有寫「約」…
你硬是要在這小點力求精確，我也沒什麼好解釋的
抱歉造成傷眼又傷腦…
claus950 wrote:
您的算法太簡化，簡化到甚至算不上P2P
我也沒有說它是P2P，只是不確定你講的「1對1的P2P」是怎樣子的運作方式
所以才舉一個比較接近「1對1」的方式，並非是指它是P2P
要比較也得有個目標，不然無法呈現差異
claus950 wrote:
因為P2P本來就不是1000人同時只連上1台主機
eMule 的 ed2k 伺服器就是以這樣型式存在
伺服器連上的節點越多，各節點分享資源的總合也越多
claus950 wrote:
以1對1的P2P來說，A給B的同時，B也可以給C，C可以給D，D可以給E，E可以給F
你這樣的運作方式就是「1對1的P2P」!?
請問節點之間是用什麼方式，彼此能取得各自擁有的資源，然後把資源分配出去 ?
這不就要有一個伺服器去連結、統計各節點擁有什麼資源，再分配資源
簡單講就是利用「以中心伺服器為主的P2P」並利用「對稱方式一個傳一個」達成資源分享
所以不就是有多少人欲分享/要求資源就有多少人連上1台伺服器 ?
如果說不需要伺服器，那麼就是每個節點也扮演伺服器的角色
因此當資源參與(分享/要求)者即節點越來越多時，各個節點同樣也必須負荷節點間的資源維護與分配
又你提出的是「1對1的P2P」，在以「對稱頻寬一個傳一個」基礎下
有什麼方法能解決各節點間「資源的定位、分配、交換及取得」
即使實現對稱頻寬，實際生活中總會有經濟、建設…等因素，無法讓每個人的速率達到最高
依照你提出的「1對1的P2P邏輯」，當下面情況發生時：
每個節點都擁有對稱頻寬，只是兩端點間的頻寬並非對等
A -> 1Gbps/1Gbps
B、C、D、E、F -> 100Mbps/100Mbps、於整體進度 0% 時加入
G -> 1Gbps/1Gbps、於整體進度 20% 時加入
H -> 1Gbps/1Gbps、於整體進度 30% 時加入
I、J、K、L、M -> 100Mbps/100Mbps、於整體進度 35% 時加入
N、O、P -> 1Gbps/1Gbps、於整體進度 40% 時加入
---------------------------------
A->B, B->C, C->D, D->E, E->F
F(100Mbps)->G
G(1Gbps)->H
H(100Mbps)->I, I->J, J->K, K->L, L->M
M(100Mbps)->N, N->O, O->P
應該可以發現「1對1的P2P」有大量閒置的頻寬
首先A就閒置了900Mbps、F僅能提供100Mbps給G
由於F->G間速率不足，隨後的H只能等待F->G->H，F變成了瓶頸
最晚加入的N、O、P，不用說也是卡在最源頭的F
而等到最前面加入的 B、C、D、E、F 完成，它們不就又閒置下來了嗎 ?
還是卡在後頭的 G、H、I、J、K、L、M、N、O、P 也能再接收大於一個節點的傳輸 ?
那麼這樣的運作方式，還是你定義的「1對1的P2P」嗎 ?
除了用於傳輸資源的連線不可少之外
隨著參與的節點數量越來越多，用於溝通各節點的連線也同樣不算少吧 ?
---------------------------------
各節點對稱頻寬下但兩端點間不對等頻寬的 BT：
0%
-----
A->B
A->C
A->D
A->E
A->F
20%
-----
A(剩餘500Mbps)->G
B、C、D、E、F(總合500Mbps)->G
30%
-----
G(1Gbps)->H
35%
-----
H->I
H->J
H->K
H->L
H->M
40%
-----
H(剩餘500Mbps)->N
I、J、K、L、M(總合500Mbps)->N
N->O
O->P
以上是 BT 簡單的分配頻寬
即使不是這樣分配，所剩餘頻寬也一定不會浪費太多
可以集合起來再利用，因此不會有過多的閒置頻寬
BT 這樣的運作方式真的在對稱頻寬出現後就不需要了嗎 ?
你的想法是不錯！
等哪天全世界任意兩端點都能以對稱頻寬做對等傳輸時，確實能減少可怕連線數！
但世界總有不完美的時候，方法沒有絕對
當下要採用什麼解決方案需視情況做應變
除非完美的世界先存在，不然不會有完美解決方案…
個人積分：2747分
文章編號：29048811
chais wrote:
你的想法是不錯！
等哪天全世界任意兩端點都能以對稱頻寬做對等傳輸時，確實能減少可怕連線數！
但世界總有不完美的時候，方法沒有絕對
當下要採用什麼解決方案需視情況做應變
除非完美的世界先存在，不然不會有完美解決方案…
確實，對於"差異頻寬"下，BT的確能夠擁有較ezpeer這類軟體更高的效率
這也是為什麼後來ezpeer會快速的被emule、BT取代掉(當然被告也是原因之一)
等等...所以"頻寬的差異"是決定P2P界，誰該走而誰該留的關鍵差異嗎??
那這頻寬的差異包不包括所謂的"上下傳不對等"呢??
好吧，你要說我鬼打牆也好，講不聽也罷
我只知道一切的工具被開發出來並且發揚光大一定有其時代背景
作者也許本意不在於解決上下傳不對等的問題，但是實作上確實是漂亮的解決了這個難題
另外，對稱頻寬之後的P2P可能著重的點不會再是效率問題(因為大家的上傳不再這麼的昂貴)而是隱密性，因為目前在P2P上流竄的幾乎都還是"不能說的秘密"
個人積分：82分
文章編號：29051069
個人積分：851分
文章編號：29052311
個人積分：1603分
文章編號：29053047
個人積分：899分
文章編號：29064785
個人積分：54分
文章編號：29065048
