Bandwidth Usage of MUDS
Threshold RPG
Does anyone know what kind of bandwidth a medium or large sized mud uses?
For example, what is a good approximation or range for a mud with 50 users
online, 100 users online, 200 users online, etc.
Does anyone have any good information on this?
-Aristotle@Threshold
Bob Farmer
In article <6a9b28$c3e$2...@usenet87.supernews.com>,
I've produced stats on this on several occassions. Basically, the
bandwidth usage is negligible. Less than 30 Kbits/sec (more like 20
Kbits/sec, probably) for 50 players for us, which is less than the
bandwidth of an analog modem. Of course, it depends on the mud, but it's
hard to imagine a scenario where a mud's bandwidth usage would be anything
to really worry about, assuming you've got a decent line (T1+).
--
Bob Farmer ucs...@unx1.shsu.edu
University Computer Services, Sam Houston State Univ. (409)294-3547
BoneZ
On 23 Jan 1998 12:13:50 -0600, ucs...@unx1.shsu.edu (Bob Farmer)
wrote:
See, I beg to differ, granted in 'theory' yah, it should be a low
bandwidth user, and yer right it is around 30-50kbits a second, but in
reality telnet itself is a bandwidth intense application, it takes 5
packets to complete the sending of one simple character. If you know
a lot about how telnet was designed, and when it was used, you'll know
what Im talkin about. Echo responses, etc etc. If you actually try
and run a mud off a 28.8k modem, which in theory is fast enough to
handle it, you'll clearly see it's not, fact of the matter is, for ONE
user that's enough, but if you get 10 users spamming directions, and
commands, you'll lag the modem, but with a T1, or higher link, it's
not as noticable cause the packet from the server can be sent faster
than that of a modem.
I agree once again that the 'theory' of it should be alow bandwidth
utilizer, but reality show's that it's more than people think.
Just my 2 cents, Im not lookin for any flames folks...
-BZ
Thierry Coutelier
With 100 users you will need about 128k even if the real traffic is below
that number. ( for small data amounts the TCP/IP overhead is sometimes
greater than the data, and a MUD produces only small data amounts)
You can count on about 2k/s per player outgoing and 10% incoming traffic.
If you want to be sure that there is never LAG on your system with 200 player
you will need a T1 or E1.
But as from experience players will have LAG anyway except you have a line
with each
ISP the players connects from. After long hours of analyzing traffic I saw
that the LAG did come
from bottlenecks somewhere on the Internet. The bottleneck was mostly
between Education sites
and commercial ISP's.
Threshold RPG wrote:
> Does anyone know what kind of bandwidth a medium or large sized mud uses?
>
> For example, what is a good approximation or range for a mud with 50 users
> online, 100 users online, 200 users online, etc.
>
> Does anyone have any good information on this?
>
---
Thierry....@remove-to-mail.prophecy.lu
http://www.prophecy.lu
http://www.linux.lu
Visit Prophecy the David Eddings MUD
telnet://mud.prophecy.lu:4000
Richard Woolcock
BoneZ wrote:
>
>On 23 Jan 1998 12:13:50 -0600, ucs...@unx1.shsu.edu (Bob Farmer)
>wrote:
>
>>In article <6a9b28$c3e$2...@usenet87.supernews.com>,
>>>Does anyone know what kind of bandwidth a medium or large sized mud uses?
>>>
>>>For example, what is a good approximation or range for a mud with 50 users
>>>online, 100 users online, 200 users online, etc.
>>>
>>>Does anyone have any good information on this?
>>
>>bandwidth usage is negligible. Less than 30 Kbits/sec (more like 20
>>Kbits/sec, probably) for 50 players for us, which is less than the
>>bandwidth of an analog modem. Of course, it depends on the mud, but it's
>>hard to imagine a scenario where a mud's bandwidth usage would be anything
>>to really worry about, assuming you've got a decent line (T1+).
>
>bandwidth user, and yer right it is around 30-50kbits a second, but in
>reality telnet itself is a bandwidth intense application, it takes 5
>packets to complete the sending of one simple character. If you know
>a lot about how telnet was designed, and when it was used, you'll know
>what Im talkin about. Echo responses, etc etc. If you actually try
>and run a mud off a 28.8k modem, which in theory is fast enough to
>handle it, you'll clearly see it's not, fact of the matter is, for ONE
>user that's enough, but if you get 10 users spamming directions, and
>commands, you'll lag the modem, but with a T1, or higher link, it's
>not as noticable cause the packet from the server can be sent faster
>than that of a modem.
A few years back a friend of mine used his 28.8 modem to let a few
people have a look at a mud he was working on. Any more than 5 or
6 players connected at once would result in the mud becoming unplayably
slow.
It is, however, a good way to advertise when looking for a free site,
as my friend found out.
KaVir.
Ben Minshall
Bob Farmer wrote:
>
> In article <6a9b28$c3e$2...@usenet87.supernews.com>,
> Threshold RPG <thre...@counseltech.com> wrote:
> >Does anyone know what kind of bandwidth a medium or large sized mud uses?
> >
> >For example, what is a good approximation or range for a mud with 50 users
> >online, 100 users online, 200 users online, etc.
> >
> >Does anyone have any good information on this?
> >
>
> I've produced stats on this on several occassions. Basically, the
> bandwidth usage is negligible. Less than 30 Kbits/sec (more like 20
> Kbits/sec, probably) for 50 players for us, which is less than the
> bandwidth of an analog modem. Of course, it depends on the mud, but it's
> hard to imagine a scenario where a mud's bandwidth usage would be anything
> to really worry about, assuming you've got a decent line (T1+).
>
> Bob Farmer ucs...@unx1.shsu.edu
> University Computer Services, Sam Houston State Univ. (409)294-3547
I have been able to get about 10 players on a 14.4 analog without
lag. All of the players did come from the same ISP as me though.
--
--------------------------------------------------
Ben Minshall bmi...@mudbucket.ml.org
Linux: The choice of a GNU generation!
--------------------------------------------------
Threshold RPG
In article <34C9BF4E...@prophecy.lu>, Thierry Coutelier <net...@prophecy.lu> wrote:
>With 100 users you will need about 128k even if the real traffic is below
> that number. ( for small data amounts the TCP/IP overhead is sometimes
> greater than the data, and a MUD produces only small data amounts)
>
>You can count on about 2k/s per player outgoing and 10% incoming traffic.
>
>If you want to be sure that there is never LAG on your system with 200 player
> you will need a T1 or E1.
The reason I was asking is because the ISP where I am moving (a pay site)
charges me differently based on my bandwidth usage. At 256kb/s it is one rate,
and 512 kb/s a different rate. I am under the impression that it would take
150-200 or more to be using more than 256. Is this a good estimate?
-Aristotle@Threshold
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
VISIT THRESHOLD ONLINE! High Fantasy Role Playing Game!
Player run clans, guilds, businesses, legal system, nobility, missile
combat, detailed religions, rich, detailed roleplaying environment.
http://www.threshold.counseltech.com
telnet://threshold.counseltech.com:23
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Aiwa
In article <34c964d6...@news.pacbell.net>,
BoneZ <bo...@necromium.com> wrote:
>On 23 Jan 1998 12:13:50 -0600, ucs...@unx1.shsu.edu (Bob Farmer)
>wrote:
>>bandwidth usage is negligible. Less than 30 Kbits/sec (more like 20
>>Kbits/sec, probably) for 50 players for us, which is less than the
>>bandwidth of an analog modem.
>See, I beg to differ, granted in 'theory' yah, it should be a low
>bandwidth user, and yer right it is around 30-50kbits a second, but in
>reality telnet itself is a bandwidth intense application, it takes 5
>packets to complete the sending of one simple character. If you know
>a lot about how telnet was designed, and when it was used, you'll know
>what Im talkin about. Echo responses, etc etc.
That's not true if you're talking about MUDs. No MUD server that I've
ever seen puts telnet clients into character mode. They all operate using
telnet's line mode, which is very bandwidth-efficient -- it uses a single
packet to send the entire line, only when the user presses 'return'. No
network traffic is generated while the user is typing the line. The MUD
server does not echo keystrokes back to the user; echoing is done by the
local telnet client. (That's why, if you're logged into a MUD, you can
always type without any apparent lag between your keystrokes and seeing
the letters appear on the screen, even when the MUD is lagged.)
You're right that in general, telnetting *can* be bandwidth intensive
because most telnet servers put the telnet client into character mode.
This means that, as you say, each keystroke has the potential to generate,
in the worst case, 6 packets (although in practice it's usually only 3).
But MUDs don't use this very inefficient model.
-Aiwa
Peter R. Sadlon
> In article <34c964d6...@news.pacbell.net>,
> BoneZ <bo...@necromium.com> wrote:
>
> >On 23 Jan 1998 12:13:50 -0600, ucs...@unx1.shsu.edu (Bob Farmer)
> >wrote:
> >>bandwidth usage is negligible. Less than 30 Kbits/sec (more like 20
>
> >See, I beg to differ, granted in 'theory' yah, it should be a low
> >bandwidth user, and yer right it is around 30-50kbits a second, but in
> >reality telnet itself is a bandwidth intense application, it takes 5
> >packets to complete the sending of one simple character. If you know
> >a lot about how telnet was designed, and when it was used, you'll know
> >what Im talkin about. Echo responses, etc etc.
>
> That's not true if you're talking about MUDs. No MUD server that I've
> ever seen puts telnet clients into character mode. They all operate using
> telnet's line mode, which is very bandwidth-efficient -- it uses a single
> packet to send the entire line, only when the user presses 'return'. No
> network traffic is generated while the user is typing the line. The MUD
The mud may not echo keystrokes back, but I can give a perfect example (on
my mud at least) to show that each keystroke is sent to the mud. Snoop a
player who isn't using a mud client (just telnetting directly) and you
will see them type out each character, it is my understanding as well that
the mud and the user keep exchanging null packets even when they are idle,
at least on my mud.
_Peter
Roger Richmond
Peter R. Sadlon wrote: The mud may not echo keystrokes back, but I can
give a perfect example (on
> my mud at least) to show that each keystroke is sent to the mud.
> Snoop a
> player who isn't using a mud client (just telnetting directly) and you
>
> will see them type out each character, it is my understanding as well
> that
> the mud and the user keep exchanging null packets even when they are
> idle,
> at least on my mud.
>
> _Peter
On my mud the keystrokes are sent in line mode, rather than character
mode, at least I can't see each keystroke from someone on a regular
telnet program(Win95's telnet..argh!) It makes sense to be using a line
mode connection for a mud, most mud's don't require something like VT100
emulation like many telnet servers do, and it's much more efficient for
sending data.
Jesse
j...@umr.edu
In rec.games.mud.lp Richard Woolcock <Ka...@dial.pipex.comNOSPAM> wrote:
: A few years back a friend of mine used his 28.8 modem to let a few
: people have a look at a mud he was working on. Any more than 5 or
: 6 players connected at once would result in the mud becoming unplayably
: slow.
I've used a 28.8 link to work on muds that weren't open yet. We used to
get 15 actives and it worked fine. I think the key is in USING the
'kludge' linemode and in the sort of thing the people are doing; if
they're mostly editing code, they probably spend some of their time
thinking instead of typing:-)
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
Richard Woolcock
j...@umr.edu wrote:
>
> In rec.games.mud.lp Richard Woolcock <Ka...@dial.pipex.comNOSPAM> wrote:
>
> : A few years back a friend of mine used his 28.8 modem to let a few
> : people have a look at a mud he was working on. Any more than 5 or
> : 6 players connected at once would result in the mud becoming unplayably
> : slow.
>
> I've used a 28.8 link to work on muds that weren't open yet. We used to
> get 15 actives and it worked fine. I think the key is in USING the
> 'kludge' linemode and in the sort of thing the people are doing; if
> they're mostly editing code, they probably spend some of their time
> thinking instead of typing:-)
Perhaps, and reading other messages on this subject it seems that other
people don't have much trouble with multiple users via a modem. All I
can say is that a friend of mine in australia put an envy mud on his
home computer with linux, a slip link and a 28.8 modem, and invited
myself (from England) and some other people (from UK/USA) to connect -
and everyone agreed that there was a lot of 'lag' if more than half a
dozen people connected at once.
KaVir.
John Adelsberger
In rec.games.mud.lp Richard Woolcock <Ka...@dial.pipex.comNOSPAM> wrote:
: Perhaps, and reading other messages on this subject it seems that other
: people don't have much trouble with multiple users via a modem. All I
: can say is that a friend of mine in australia put an envy mud on his
: home computer with linux, a slip link and a 28.8 modem, and invited
Envy is your problem. The network layer used there isn't too poorly
written, but afaik, it knows of no such beast as linemode, which is
your real saver in terms of netlag.
Andy Finkenstadt
In article <6a9b28$c3e$2...@usenet87.supernews.com>,
Threshold RPG <thre...@counseltech.com> wrote:
>Does anyone know what kind of bandwidth a medium or large sized mud uses?
>
>For example, what is a good approximation or range for a mud with 50 users
>online, 100 users online, 200 users online, etc.
>
>Does anyone have any good information on this?
>
>-Aristotle@Threshold
I work for the company that has some of the largest "MUDS" in existence,
with 5,000 simultaneous players across two games. The hardware to support
these players cost somewhere in the neighborhood of $300,000 each, with
yearly maintenance costs of about $100,000 including on-site depot and
parts replacement.
The amount of bandwidth we needed to support all of the players was on
the order of 10.5 megabits per second (7 T-1 lines) without having
substantial congestive-related delay. When we added web access
capabilities, our bandwidth needs shot up a bit but not as much as one
might have thought.
So that works out to be about 200 bytes per second of bandwidth per
player, every second during peak load.
Andy
--
Andrew Finkenstadt (http://www.panix.com/~genie/)
"The web is not a piece of paper." - http://html.dm.net/
Cameron Kaiser
"Peter R. Sadlon" <prsa...@calcna.ab.ca> writes:
>player who isn't using a mud client (just telnetting directly) and you
>will see them type out each character, it is my understanding as well that
>the mud and the user keep exchanging null packets even when they are idle,
>at least on my mud.
At least for MudOS, I use boring old MS Telnet and vanilla Un*x telnet,
and both run in line mode by default. I have to physically put them in
character mode if I'm really interested in that (MS Telnet doesn't even seem
to have that option, now that I investigate ...).
Evergreen@Icewind
skaidi.hifm.no 2021
--
Cameron Kaiser
cdkaiser at concentric dot net (it hasn't helped the spam yet though)
*** visit the Spectre Server at www.sserv.com
*** C64 software lives! www.computerworkshops.home.ml.org
Tatu P Saloranta
"Peter R. Sadlon" <prsa...@calcna.ab.ca> writes:
>> In article <34c964d6...@news.pacbell.net>,
>> BoneZ <bo...@necromium.com> wrote:
>>
>> >On 23 Jan 1998 12:13:50 -0600, ucs...@unx1.shsu.edu (Bob Farmer)
>> >wrote:
>> >reality telnet itself is a bandwidth intense application, it takes 5
>> >packets to complete the sending of one simple character. If you know
Nope. In worst case it'd be 4 packets; char+ack, echo+ack. And usually,
depending on whether delayed ack is used by tcp-stack, it'd be 3
instead. But that doesn't usually matter as:
>> >a lot about how telnet was designed, and when it was used, you'll know
>> >what Im talkin about. Echo responses, etc etc.
>>
>> That's not true if you're talking about MUDs. No MUD server that I've
>> ever seen puts telnet clients into character mode. They all operate using
>> telnet's line mode, which is very bandwidth-efficient -- it uses a single
>> packet to send the entire line, only when the user presses 'return'. No
>> network traffic is generated while the user is typing the line. The MUD
>The mud may not echo keystrokes back, but I can give a perfect example (on
>my mud at least) to show that each keystroke is sent to the mud. Snoop a
>player who isn't using a mud client (just telnetting directly) and you
As someone else already pointed out, some telnet-clients may decide to
use char-mode by default, but generally that's not what they do when
the mud is _not using the default telnet-port_. Even if it is, server could
(try to) negotiate for full linemode. Not sure if servers in general do
that, though.
Then again, at least some servers (Amylaar LP-mud gamedriver for example,
probably many/most others too) allow for changing to char-mode, if need
be. Perhaps your mud server deliberately sets connections to char-mode?
>will see them type out each character, it is my understanding as well that
>the mud and the user keep exchanging null packets even when they are idle,
>at least on my mud.
No, completely untrue for tcp-stacks. Except for keepalives, which are
sent (if used at all) after connectiong being idle for long time,
like 2 hours or so, to make sure tcp-connection used 'is still alive'
(and there are lots of people who think this is an evil thing to do
in any case...) Then again... Mud-server could try sending probes too,
but that only happens when the send window of tcp has shrank to 0
(due to client-application not being able to handle all the traffic
or so... unlikely).
--
Tatu Saloranta, aka Doomdark.
doom...@cc.hut.fi
Threshold RPG
In article <6adub9$h...@ds2.acs.ucalgary.ca>, "Peter R. Sadlon" <prsa...@calcna.ab.ca> wrote:
>The mud may not echo keystrokes back, but I can give a perfect example (on
>my mud at least) to show that each keystroke is sent to the mud. Snoop a
>player who isn't using a mud client (just telnetting directly) and you
>the mud and the user keep exchanging null packets even when they are idle,
>at least on my mud.
I've tested this and approximately 1 out of 50 users on my mud telnets in
character mode.
Emanuele Benedetti
>Does anyone know what kind of bandwidth a medium or large sized mud uses?
>
>For example, what is a good approximation or range for a mud with 50 users
>online, 100 users online, 200 users online, etc.
Leu, the Italian MUD in which i am implementor, that has an average of 30
players and peaks of 60, fullfill the bandwith of a 64K serial line. But the
Italian language is much more prolix than English ad we use a lot of ANSI
codes.
--
Emanuele
Ryan Haksi
One thing you will have to carefull of is to use ANSI color codes very
sparingly.
On my own mud which makes heavy use of ANSI color, some screens (ie like
the score screen) scroll noticeably slower (although just barely) even
on a T1 connection.
As a worst case example:
80 chars of text is roughly 80 bytes of data (+ overhead of course but
lets ignore that)
80 chars of text, changing color for every character is:
<esc>[<intensity>;<fg>3;<bg>4m<char>x80 = 11x80 = 880 bytes of data, for
*ONE* line of text. Granted with a ludicrous amount of color commands.
(Although on my mud you can achieve this worst case by using the rainbow
speech god command...)
I would also tend to think that transferring plain text <ie data limited
largely to the 26 lower case letters> would make excellent use of modems
compression abilities, so you'll tend to get better than the normally
expected throughput out of your modem.
--
---
Play Crimson/2799 -+> http://www.engr.uvic.ca/~clesiuk/Crimson2 <+-
Ryan Haksi "Ha ha, that makes six shots..."
cry...@infoserve.net -famous last words
telnet://daydream.uvic.ca:5000 "I re-loaded" - the rebuttal
David Bennett (pinkfish)
ucs...@unx1.shsu.edu (Bob Farmer) writes:
>I've produced stats on this on several occassions. Basically, the
>bandwidth usage is negligible. Less than 30 Kbits/sec (more like 20
>Kbits/sec, probably) for 50 players for us, which is less than the
>bandwidth of an analog modem. Of course, it depends on the mud, but it's
>hard to imagine a scenario where a mud's bandwidth usage would be anything
>to really worry about, assuming you've got a decent line (T1+).
Yeah. This is about the same for dw. A web site uses way way
more bandwidth than a mud.
Glued to the frogs,
David.
David Bennett (pinkfish)
bo...@necromium.com (BoneZ) writes:
>See, I beg to differ, granted in 'theory' yah, it should be a low
>bandwidth user, and yer right it is around 30-50kbits a second, but in
>reality telnet itself is a bandwidth intense application, it takes 5
>packets to complete the sending of one simple character. If you know
>a lot about how telnet was designed, and when it was used, you'll know
>what Im talkin about. Echo responses, etc etc. If you actually try
Oh ... Really? In which telnet implementaiont is this? It takes
1, packet to send a line of text to a mud (if your using the right telnet
application) otherwsie it require 1 packet per character, less if you type fast
enbough :) Because the client end does the echoing... Not the server (ie mud).
The reason you see problems is probably due to latency and the overhead of
ppp. I assure you that these are the stats from a running mud with 50 players
on.
Blue with purple chickens,
David.
David Bennett (pinkfish)
"Peter R. Sadlon" <prsa...@calcna.ab.ca> writes:
>The mud may not echo keystrokes back, but I can give a perfect example (on
>my mud at least) to show that each keystroke is sent to the mud. Snoop a
>player who isn't using a mud client (just telnetting directly) and you
>will see them type out each character, it is my understanding as well that
>the mud and the user keep exchanging null packets even when they are idle,
>at least on my mud.
This is only true for stupid telnet clients, ie ones on windows :)
The KEEPALIVE stuff is at a tcp level. The packets are
not sent frequntly though. Once every 5 minutes or
something. You could always edit your mud source and turn this
off (if you have it on that is). I don't know of any mud servers
that do this by default however...
(Whic is why you get a net dead when you actually get around to telling
someon something).
Keeping the frogs alive,
David.
Treasure
Just to add my own experiences to the pile...
We had a 64K ISDN line to our apartment, all 8 apartments in the building
were freinds of mine and we all shared it... with all their ftp, www, etc.
traffic (over 20 people) we still ran 1 diku and 3 mush's and we watched the
line use statistics, we never got it higher than 75%, and that was once...
average line use was less than 25%... there were no complaints of lag on
our ISDN... lag between other sites... well that is a different problem
and not a fault of the 64k connection.
As for a modem (14.4 or 28.8), maybe if the network layer of the game
is written well and your players use line-mode... never tried it so I
am just speculating.
-Indium
--
ATTENTION: Despite Any Other Listing of Product Contents Found
Hereon, the Consumer is Advised That, in Actuality, This Product
Consists Of 99.9999999999% Empty Space.
Tim Hollebeek
Thierry Coutelier wrote:
>
> With 100 users you will need about 128k even if the real traffic is below
> that number. ( for small data amounts the TCP/IP overhead is sometimes
> greater than the data, and a MUD produces only small data amounts)
Not true. For the vast majority of MUDs, incoming data is completely
overwhelmed by outgoing data, which is produced in fairly large (e.g.
>256 byte each) chunks.
-Beek
Tim Hollebeek
Threshold RPG wrote:
>
> In article <6adub9$h...@ds2.acs.ucalgary.ca>, "Peter R. Sadlon" <prsa...@calcna.ab.ca> wrote:
> >my mud at least) to show that each keystroke is sent to the mud. Snoop a
> >player who isn't using a mud client (just telnetting directly) and you
> >will see them type out each character, it is my understanding as well that
> >the mud and the user keep exchanging null packets even when they are idle,
> >at least on my mud.
>
> character mode.
That's about what's I've seen. It seems that about 1 out of 50 telnet
clients is so lame that it ignores the suggestion to use linemode.
Easier to write a client that insists on doing things it's way, I guess.
-Beek
Holly Sommer
Tim Hollebeek wrote:
: Not true. For the vast majority of MUDs, incoming data is
: completely overwhelmed by outgoing data, which is produced in
: fairly large (e.g. 256 byte each) chunks.
Yeah, really. Think about the difference in typing "l" and
what you get back.
-Holly, babbling :)
--
Cameron Kaiser
Holly Sommer <SNIPh...@micro.ti.comSNIP> writes:
>: Not true. For the vast majority of MUDs, incoming data is
>: completely overwhelmed by outgoing data, which is produced in
>Yeah, really. Think about the difference in typing "l" and
>what you get back.
Especially on those muds where QC refuses areas with rooms less descriptive
than the garden-variety expository essay. (Mmmm, stilted expression ...)
David Gay
In article <34D01B00...@wfn-shop.princeton.edu> Tim Hollebeek <t...@wfn-shop.princeton.edu> writes:
Thierry Coutelier wrote:
>
> With 100 users you will need about 128k even if the real traffic is below
> that number. ( for small data amounts the TCP/IP overhead is sometimes
> greater than the data, and a MUD produces only small data amounts)
Not true. For the vast majority of MUDs, incoming data is completely
overwhelmed by outgoing data, which is produced in fairly large (e.g.
>256 byte each) chunks.
While this is true, the difference isn't quite as great as you think: the
1-10 character command you receive is surrounded by a tcp and an ip header,
which add something like 30 bytes if I'm not confused. So if you receive a
5 character command and send a 100 character response, the ratio is more
like 4 to 1 (130 vs 35) rathen than 20 to 1...
On MUME, we compress the output (but not the input), as a result input bandwith
is something like 60% of output bandwidth.
--
David Gay - Yet Another Starving Grad Student
dg...@cs.berkeley.edu
Bob Farmer
In article <6adbql$pdh$2...@usenet87.supernews.com>,
Threshold RPG <thre...@counseltech.com> wrote:
>In article <34C9BF4E...@prophecy.lu>, Thierry Coutelier <net...@prophecy.lu> wrote:
>>With 100 users you will need about 128k even if the real traffic is below
>> that number. ( for small data amounts the TCP/IP overhead is sometimes
>> greater than the data, and a MUD produces only small data amounts)
>>
>>
>>If you want to be sure that there is never LAG on your system with 200 player
>> you will need a T1 or E1.
>
>
>The reason I was asking is because the ISP where I am moving (a pay site)
>charges me differently based on my bandwidth usage. At 256kb/s it is one rate,
>and 512 kb/s a different rate. I am under the impression that it would take
>150-200 or more to be using more than 256. Is this a good estimate?
>
>-Aristotle@Threshold
You would need more than 200 players to use up 256Kbits/sec, from what
I've seen.
Also, after my original post on this subject where I said that a normal
mud's bandwidth usage was "less than the bandwidth of an analog modem",
several people replied saying that you can't run a mud on a modem, it's
too slow, can only support 5-10-15 users, etc etc. I didn't mean to imply
you could. Too much latency and PPP overhead on a modem connection.
Bob Farmer
>> BoneZ <bo...@necromium.com> wrote:
>>
>> >On 23 Jan 1998 12:13:50 -0600, ucs...@unx1.shsu.edu (Bob Farmer)
>> >wrote:
>>
>> >bandwidth user, and yer right it is around 30-50kbits a second, but in
>> >reality telnet itself is a bandwidth intense application, it takes 5
>> >packets to complete the sending of one simple character. If you know
>> >a lot about how telnet was designed, and when it was used, you'll know
>> >what Im talkin about. Echo responses, etc etc.
>>
>> ever seen puts telnet clients into character mode. They all operate using
>> telnet's line mode, which is very bandwidth-efficient -- it uses a single
>> packet to send the entire line, only when the user presses 'return'. No
>> network traffic is generated while the user is typing the line. The MUD
>
>my mud at least) to show that each keystroke is sent to the mud. Snoop a
>player who isn't using a mud client (just telnetting directly) and you
>will see them type out each character, it is my understanding as well that
>the mud and the user keep exchanging null packets even when they are idle,
>at least on my mud.
>
What exactly is "telnetting directly" supposed to mean?
Almost no telnet clients use character mode when connecting to a mud.
Normal UNIX telnets sure don't... Players in character mode are very
rare, as someone else has already said...
mor...@niuhep.physics.niu.edu
ucs...@unx1.shsu.edu (Bob Farmer) writes:
>Almost no telnet clients use character mode when connecting to a mud.
>Normal UNIX telnets sure don't... Players in character mode are very
>rare, as someone else has already said...
May I suggest that just because the server sees line mode doesn't mean
the player does.
I am not sure what the cause is of following situation but it is something
that should be addressed in some way. I haven't Mudded for a long time
so the specifics of the driver, if I ever knew them, are lost to my memory.
The following symptoms were reported by a number of people on the mud's
local board.
telnet in,
no ability to delete anything that is typed or to back up and type over
anything.
My telnet client is a character connection by default and showed the above
behaviour, if I set it to line mode there was no problem.
Others, specifically one with a Mac client, couldn't figure out how to set
to line mode.
It is possible that the mud had a defective character mode server.
In any case I suggest that it may be useful for admins to know what
clients for the major platforms work well with their mud.
Robert
Nathan Boydston
In rec.games.mud.diku mor...@niuhep.physics.niu.edu wrote:
: The following symptoms were reported by a number of people on the mud's
: local board.
: telnet in,
: no ability to delete anything that is typed or to back up and type over
: anything.
Whilst looking at some generic diku code i noticed this: although the
mud/server may actually read the chars from the network, it doesnt bother
to do anything with them until you send and end of line. If one were to
want something like that in a mud, I think it would be groovy to see a
sort of 'pluggable' CLI interface similar to a Unix login shell. Some
users may prefer a generic login and base interface, while others may
prefer a command history, aliases, name completion, etc.
Just thoughts.
Nate
--
drpe...@frii.com
Tim Hollebeek
In article <s71hg6l...@barnowl.CS.Berkeley.EDU>, dg...@barnowl.CS.Berkeley.EDU writes:
> <34D01B00...@wfn-shop.princeton.edu>
> NNTP-Posting-Host: barnowl.cs.berkeley.edu
> In-reply-to: Tim Hollebeek's message of Thu, 29 Jan 1998 01:00:32 -0500
> X-Newsreader: Gnus v5.1
> Xref: cnn.Princeton.EDU rec.games.mud.admin:32313 rec.games.mud.diku:56450 rec.games.mud.lp:27426 rec.games.mud.misc:29839
>
>
> In article <34D01B00...@wfn-shop.princeton.edu> Tim Hollebeek <t...@wfn-shop.princeton.edu> writes:
> Thierry Coutelier wrote:
> >
> > With 100 users you will need about 128k even if the real traffic is below
> > that number. ( for small data amounts the TCP/IP overhead is sometimes
> > greater than the data, and a MUD produces only small data amounts)
>
> Not true. For the vast majority of MUDs, incoming data is completely
> overwhelmed by outgoing data, which is produced in fairly large (e.g.
> >256 byte each) chunks.
>
> While this is true, the difference isn't quite as great as you think: the
> 1-10 character command you receive is surrounded by a tcp and an ip header,
> which add something like 30 bytes if I'm not confused. So if you receive a
> 5 character command and send a 100 character response, the ratio is more
> like 4 to 1 (130 vs 35) rathen than 20 to 1...
For a social MUD, that's true. But for "game" MUDs, 100 characters is
an absurdly short response. Usually, all the output from a single command
is cached and sent at once. If it's a room desc on a well QC'd MUD,
that's 1-2k; combat (say 6 lines/round at 50 chars each, which isn't
at all rare on popular MUDs, with spells, HP monitors, etc) and a line
of combat is alread 300 bytes. The players which account for most of
the bandwidth will be using macros (sent in huge chunks) or aliases
that are expanded to 100s of commands server side anyway, so the input
actually can be smaller than you might guess.
So 20:1 is certainly easily achievable. Social MUDs will have much lower
ratios, but their total bandwidth is usually an order of magnitude lower
as well.
---------------------------------------------------------------------------
Tim Hollebeek | "Everything above is a true
email: t...@wfn-shop.princeton.edu | statement, for sufficiently
URL: http://wfn-shop.princeton.edu/~tim | false values of true."
mor...@niuhep.physics.niu.edu
>: The following symptoms were reported by a number of people on the mud's
>: local board.
>: telnet in,
>: no ability to delete anything that is typed or to back up and type over
>: anything.
>Whilst looking at some generic diku code i noticed this: although the
>mud/server may actually read the chars from the network, it doesnt bother
>to do anything with them until you send and end of line.
Thanks for the input. That sounds like it assumes line mode or is
that specifically in char mode? Lousy handling in that case.
I have received email which basically agreed with my guess, that the
client was in character mode and the server was in line mode, each
expecting the other to do the work.
Which suggests that the statements that very few clients run character
mode may not be accurate, and that when people approach this problem
they should be aware of the problem and minimally document the expectations
and capabilities of the server.
Robert
Vasco Alexandre Da Silva Costa
Nathan Boydston (drpe...@io.frii.com) wrote:
: In rec.games.mud.diku mor...@niuhep.physics.niu.edu wrote:
: : The following symptoms were reported by a number of people on the mud's
: : local board.
: : telnet in,
: : no ability to delete anything that is typed or to back up and type over
: : anything.
: Whilst looking at some generic diku code i noticed this: although the
: mud/server may actually read the chars from the network, it doesnt bother
: to do anything with them until you send and end of line. If one were to
: want something like that in a mud, I think it would be groovy to see a
: sort of 'pluggable' CLI interface similar to a Unix login shell. Some
: users may prefer a generic login and base interface, while others may
: prefer a command history, aliases, name completion, etc.
I code on an Envy mud and i think that would be cool too. I have felt the
need for a user friendly mud shell in a long time. What i did was to put
aliases and the tcsh "?" and "^" stuff in so i had command history.
However nothing beats doing an "up arrow" to use the previous command or
using the left and right keys to do line editing like on tcsh/bash.
Since my knowledge of the TELNET protocol is near zero i can't to much
about it... From telnet.h it seems that the server can send a control
sequence to inform the telnet client to use "character by character mode"
and then you could use the ANSI/VT100 escapes like ^[[A and such for the
arrow keys, however i haven't bothered myself to much with it.
Zen
--
Vasco Alexandre da Silva Costa, student @ Instituto Superior Tecnico,
Technical University of Lisbon - Software & Computer Engineering
Mike McGaughey
[Posted and mailed]
mor...@niuhep.physics.niu.edu writes:
>
> I have received email which basically agreed with my guess, that the
> client was in character mode and the server was in line mode, each
> expecting the other to do the work.
>
> Which suggests that the statements that very few clients run character
> mode may not be accurate, and that when people approach this problem
> they should be aware of the problem and minimally document the expectations
> and capabilities of the server.
No - it's the clients that are wrong.
Telnet clients *must* start in line mode, and negotiate for character
mode (actually SGA), otherwise they are broken. It's part of the
standard. One common telnet client (BSD 4.2 telnet?) is certainly
broken this way (this is unforgivable).
Servers which do not intend to use character mode can work around
this, to some extent, by starting off proceedings with a new telnet
connection by sending an IAC WONT SGA; this *should* be ignored by
a well-implemented telnet client, and *should* kick a character
mode client into a sane state. Unfortunately, some telnet clients
will be confused by this. C'est la vie.
Cheers,
Mike.
--
Mike McGaughey AARNET: mm...@cs.monash.edu.au
"Thousands at his bidding speed,
And post o'er land and ocean without rest" - Milton.
mor...@niuhep.physics.niu.edu
mm...@mjolnir.cs.monash.edu.au (Mike McGaughey) writes:
>mor...@niuhep.physics.niu.edu writes:
>> I have received email which basically agreed with my guess, that the
>> client was in character mode and the server was in line mode, each
>> expecting the other to do the work.
>>
>> Which suggests that the statements that very few clients run character
>> mode may not be accurate, and that when people approach this problem
>> they should be aware of the problem and minimally document the expectations
>> and capabilities of the server.
>No - it's the clients that are wrong.
[snip of enlightening explanation of how things are supposed to be deleted]
>mode client into a sane state. Unfortunately, some telnet clients
>will be confused by this. C'est la vie.
Please note that this is not meant as a flame.
I take exception to your starting your sentence with "No" and ending
your post with "C'est la vie"
The evidence suggests we have no good numbers about how many clients
run in character mode, but from my small experience it is not a negligable
number. So putting in a short paragraph or two in the help files under
"telnet problems" or "line editing problems" or some such seems to be
a fairly minimal amount of work that would reduce the frustration
level of some number of players.
Robert