Re: [討論] 4040...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Aurim.bbs@ptt.cc (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:PaulLiu.bbs@bbs.cis.nctu.edu.tw
-----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-----
討論串 (同標題文章)
mud 近期熱門文章
13
23
PTT遊戲區 即時熱門文章
37
53
29
44