-----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-----