-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [email protected] (Who cares?) wrote: >個人對這類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的價位也還好（個人如此認為，假使有個有正職收入的金主在養這 >條線），這類資料壓縮通信協定的好處就顯得很不明顯了。 何不親自來 4040 體驗一下這些常用指令: sc, i, eq, prac 分別以 telnet, 及 tt++ 來跑, *肉眼*可見的delay... 就如同你說的, MTU 是 512 byte, 所以你會感覺差不多在512的地方會頓一下. (目前只有64k upload) 雖然你程式是一行一行往外送, 但不是立刻flush, 而是很快的接著送, 系統內部都有buffer, 短時間連續send, 是會接在一起變成一個封包的. 也因此這類一頁資訊的指令, 肉眼就可以看出差別... 而4040 目前64k 頻寬真的很不夠?? 不見得, 以 4040 現在人數來看, 64k 也可以很歡樂, 而且從 mrtg 上看, 跟本離64k上限很遠. 但是不壓縮還是會看得到那個頓一下... 更明顯的是 spell 這個指令, 一次兩三頁..不壓縮就頓好幾次 壓縮後居然不會頓...也就是壓縮後header+資料<MTU 然後你還可以試試 user 這個指令(先save,backup), 他會印出亂數(加密後的資料)的base64編碼兩三頁 也就是無法壓縮(頂多 base64->binary的壓縮率), 這時就算你用 tt++ 有 MCCP 壓縮, 也會一頓一頓的啦... 當然要是你沒有 4040 hero char, 有些指令可能要 hero(lv 36) 才能跑.... 這個我就幫不了忙了!! (找人幫的話一天應該練得到) - -- PaulLiu(劉穎駿) E-mail address:[email protected] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFDe25AoQj7xTSiaUYRAp7ZAJsG9/Ke+3aEYEvj08KrL4jeZ47wOwCfbTA0 j4CIXuLr0draOQKMud4w++E= =Lace -----END PGP SIGNATURE-----