※ 引述《Ying-Chun Liu <[email protected]>, 看板: mud》之銘言： : 還是請各位玩家盡量使用 tt++ v1.9x 及 zmud v6.0 以上版本 : 最近已統計出 MCCPv2 壓縮率, 約在 1/3 ~ 1/7 之間. 多半都是 1/4 的壓縮率 : 也就是原本要傳 4M, 只要傳1M 就傳完了. 個人對這類telnet/mud用壓縮協定有個疑問，就是表面上傳輸的資料量變少了， 可是TCP封包數有變少嗎？ 像是chat channel上頭的訊息，多半不會超過256 bytes，也許128或160 bytes 都不到，可是每捲個一行就必須送一個封包出來傳這些訊息。像這一類的東西， 本來就不會超過1536 bytes的IEEE 802.3訊框承載資料大小上限，也多半不會超 過一些xDSL線路上頭512 bytes MTU的限制。假使畫面中夾帶的ansi code有一半 多，也要四行滿滿不繞行的房間或mob敘述才能超過512 bytes (80欄寬的終端機畫面) 。無論merc或LP MUD系統，單獨一個戰鬥敘述多半都不會有那麼長，不同次對socket 寫入也很難要求都擠在同個封包中送出。 如果封包數沒減少多少，儘管傳輸的資料量可能縮減成1/3到1/7之間，對於server 端的區域網路封包碰撞問題的改善應該不大，對於提升xDSL線路的頻寬利用率幫助 應該也不會太大才是。 以上是個人感覺...這樣的資料壓縮對於透過行動無線網路（尤其GPRS）玩MUD的人 來說，其實省不到太多錢...以前KK還在清華，上線人數可以到千人上限時，ruby 說當時外送訊息頻寬需求為1 Mbps。今天台灣ADSL上傳頻寬1Mbps的也出來了，較低 上傳頻寬512Kbps的價位也還好（個人如此認為，假使有個有正職收入的金主在養這 條線），這類資料壓縮通信協定的好處就顯得很不明顯了。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.221.35.208