Australian MU* ban. Still in effect?
Gym Z. Quirk
e-mail from a person in australia inquiring about one of the MU*s
related to the subject matter. I informed the querant of the ban on
intercontinental MU*s that came down this past March.
I was wondering if the ban is still in effect, or if the
situation has changed at all?
--
Capt. Gym Z. Quirk (Known to some as Taki Kogoma) qu...@pioneer.unm.edu
I'll get a life when someone demonstrates that it would be superior to
what I have now...
Mitchell Brandsma
I don't think it's a ban so much as being frowned upon by AARNET. They'd
rather have people writing "real programs" than playing games... and have
the power to complain to/threaten system administrators whose machines are
"abusing" their resources. Sorry if this sounds harsh.
That's the picture I get anyway. Oh, our mud is up and running now, but we
haven't got a live AARNET link so they won't mind. All you need is an account
here on DIALix and a modem and enough to pay the bills...
Regards,
- Meetch (mee...@DIALix.oz.au :)
Jonathan Barrymore Dix
I have these two BIG errors, with io.c and indent.c of a 3.1.2
I running a 2.4.5 mudlib, and running on a ultrix unix.
This is a log of the errors when I do a make install.utils
and it lockes at this point with these errors...All I need is the
indent executable and I will have a 3.0 that works....Any help
is appreciated...
log as follows:
Installing in indent.
cc -g -c indent.c
ccom: Warning: indent.c, line 270: enumeration type clash, operator =
type_code = lexi();
--------------------^
ccom: Warning: indent.c, line 399: enumeration type clash, operator !=
if (type_code != 0)
------------------------^
ccom: Warning: indent.c, line 401: enumeration type clash, operator =
type_code = lexi();
----------------------------^
ccom: Warning: indent.c, line 410: enumeration type clash, operator ==
if (type_code == 0) {
--------------------^
ccom: Warning: indent.c, line 746: enumeration type clash, operator !=
if ((!sp_sw || hd_type != forstmt) && parser_state_tos->p_l_follow
>
0) {
---------------------------------------^
ccom: Warning: indent.c, line 881: enumeration type clash, operator =
hd_type = swstmt;
----------------------^
ccom: Warning: indent.c, line 889: enumeration type clash, operator =
(*token == 'w' ? whilestmt : forstmt));
-------------------------------------------------------^
cc -g -c io.c
ccom: Error: io.c, line 468: syntax error
else if (*p == 0)
-----------------^
ccom: Error: io.c, line 489: syntax error
if (inhibit_formatting)
---^
ccom: Error: io.c, line 490: syntax error
{
----^
ccom: Error: io.c, line 493: redeclaration of output
(--(output)->_cnt>=0?
((int)(*(output)->_ptr++=(unsigned)(*p))):_flsbuf
((unsigned)(*p),output));
--------------------------------------------------------------------------
----------------------^
ccom: Error: io.c, line 494: syntax error
while (*p++ != '\n');
----------------^
*** Error code 1
Stop.
*** Error code 1
Stop.
*** Error code 1
Stop.
I got the 3.1.2 from alcazar, If I am missing anything please mail me,
I have gotten this far and now it lockes up please help!!!
DEsperate and VERY CLOSE...I have a working master but I need the
indent so that I can login...
Ryan A. Whelan
>In my capacity as keeper of the FAQL in another group, I received
>e-mail from a person in australia inquiring about one of the MU*s
>related to the subject matter. I informed the querant of the ban on
>intercontinental MU*s that came down this past March.
>
>I was wondering if the ban is still in effect, or if the
>situation has changed at all?
Out of curisity, who enforces such BANS?
--
Ryan Whelan Only Amiga Makes It Possible?!?!?!?!
rwh...@gmuvax2.gmu.edu
-----------------------------------------------------------------------------
Mike Mc Gaughey
>In <h#vn...@lynx.unm.edu> qu...@pioneer.unm.edu (Gym Z. Quirk) writes:
>>I was wondering if the ban is still in effect, or if the
>>situation has changed at all?
>I don't think it's a ban so much as being frowned upon by AARNET. They'd
>rather have people writing "real programs" than playing games... and have
>the power to complain to/threaten system administrators whose machines are
>"abusing" their resources. Sorry if this sounds harsh.
Mmm. AARNET is funded by the government for `academic and research
purposes'. There is plenty of bandwidth within australia (except for
where there isn't :), so local mudding isn't a serious problem.
Mudding over the international link has been measured and found to take
a significant proportion of available resources.
`Significant' means (according to figures from people working there)
about 10% or so of traffic. May not seem like much compared to FTP -
but if traffic were 10% less, the international link upgrade could have
been delayed for two or three months. Considering AARNET's charter,
and the large costs in maintaining the upgraded link, it's rather
unsurprising that they stomped their little feet about it*.
Mike.
* reflecting my amusement at an email I received saying "We can go
straight to your VC and ask him to explain why your mud exists on the
network" (my mud does real research - has my PhD at the bottom level of
the server, and, due to the efforts of Geoff Wong, our HOD's economic
model at the bottom level of the game).
--
Mike McGaughey AARNET: mm...@bruce.cs.monash.edu.au
"Head stompin', ass kickin', finger licking nastiness"
...
>(at least, that's what they claim :). People _are_ interested in
>making sure they can justify their expenses to the people that fund
>them - the government and the other member organisations. While
>mudding is low-volume or close to nonexistant, noone really cares.
>When it is enough of a load to (potentially) become a political problem -
>let's face it, anything involving government money is politically
>sensitive - people start to get nervous, and the Big Sticks (tm) are
>wielded.
Has anyone ever tabulated statistics from a "large mud" to find out
how much bandwidth one of those puppies eats up?
I can't help but think the aussies were more motivated by cost then
by lack of bandwidth (though they do have a nice setup for bottle-
necking). I once saw a list of charges for satellite link-up time,
damn outrageous.
--
Edmond L. Meinfelder // In a gust of wind the white dew
// On the Autum grass // Scatters like a broken necklace.
Robert Michael Gutierrez
The following views do not represent the National Aeronautics and Space
Administration, The NASA Science Internet Office, The NASA Office of Space
Science and Applications, or any other affilitated NASA government organizations,
or any of their representatives.
Now, why the disclaimer? Because NSI (NASA Science Internet) administers
in cooperation with The Pacific Network (PACCOM) consortium the only Internet
line to Australia and Korea at the present time.
Now ...
emei...@gmuvax2.gmu.edu (...) writes:
|> mm...@cs.monash.edu.au (Mike Mc Gaughey) wrote:
|> >(at least, that's what they claim :). People _are_ interested in
|> >making sure they can justify their expenses to the people that fund
|> >them - the government and the other member organisations. While
|> >mudding is low-volume or close to nonexistant, noone really cares.
|> >When it is enough of a load to (potentially) become a political problem -
|> >let's face it, anything involving government money is politically
|> >sensitive - people start to get nervous, and the Big Sticks (tm) are
|> >wielded.
Yes, when you have enough agencies auditing on what is going on and over
your network, you have to answer to those auditors. When a circuit/line
is installed to a particular place, and that line is allocated (and paid
for) for a particular use, you *have* to start asking questions on why
the circuit/line is being clogged up with other traffic that has nothing
to do with the original use. At that point, you have no choice but to
start making "policy decisions" (ie: start filtering Internet traffic).
|> Has anyone ever tabulated statistics from a "large mud" to find out
|> how much bandwidth one of those puppies eats up?
Good question. We had a problem earlier this week when KIT-MUD came
on line in Korea. We saw the line get saturated out, and we just thought
the circuit was being used to transfer much needed NASA data for the
originators of the line (Korea Advanced Institute of Science and Techonolgy)
and such pretty much ignored it. Well, the traffic didn't go away, and
a couple of days later, we started checking around (fairly trivial for
somebody experienced in networking like myself) and shortly discovered
that a good 80% of the traffic was going to KIT-MUD. This was over
a 56 kpbs connection (yes, international links are expensive). Well,
again, when 80% of your bandwidth is going for a MUD ... you can guess
what happened.
|> I can't help but think the aussies were more motivated by cost then
|> by lack of bandwidth (though they do have a nice setup for bottle-
|> necking). I once saw a list of charges for satellite link-up time,
|> damn outrageous.
Again, when traveling across the ocean, and damn few choices for international
carriers, you main motivation will always be cost.
Please, I am not against MUDs or mudding (or any other *ing), but you
do have to remember that a number of these sites have circuits in usually
for one particular purpose. Not like big-name educational institutions
like Berkeley, MIT, Stanford, etc, where they have multiple T-1 or T-3
(1.544 mbps or 45 mbps) connections and bandwidth to spare. We have a
number of places that have 56kbps (and even a couple of 9.6kbps!) as their
only connection because they originally intended that whole connection to
serve only one purpose. What do you do when you don't have the bandwidth
anymore to accomplish your original project/task/whatever?
Weither you are sensetive to other people's needs or not, that is something
only all of you will know. I'm all for development of MUDs in general using
other transport mechanisims (like UDP, etc) but also, be considerate of
where you place the MUD and how popular you expect it to be. The Korean
mess was a big headache, politically, and it cause a lot of grief. But
most importantly, it caused a lot of people to remember now that MUDs
just are "bad" and now taken care of appropriately ...
Again, just a personal view from sombody who manages a network where all
this mudding travels over.
rob.
p.s.. The above article about the Aussie ban was the only one in my news
spool. Does anybody have the previous articles?? I'd like to read them,
and would be appreciative of whoever has them to send me a copy (after
e-mailing me to make sure I didn't already get them from somebody else).
Thanks!!! :)
Howard
Can someone explain to me how a simple MUD chews up 80% of any given data line
faster then 9600 BAUD? Here are the stats for a MUD named AfterFive. I've
had between 15 and 50 users on at any given time.
AfterFive stats:
Up since: Fri Sep 18 16:34:46 1992
User time used (CPU secs)........6310.32
System time used(CPU secs).......1224.65
Messages sent via socket(s)......1880828
Messages received via socket(s)..332475
Folks, This is a TINY amount of data. I ftp more then that on an HOURLY basis
during the weekdays. Yet this is the usage for my MUD less then 48 hours. I'm
not trying to flame anyone. I just would like to see HARD FACTS. NUMBERS
posted when talking about resource utilization with MUDS.
A little over 2 megs isn't much in my book...........
******************************************************************************
* Howard *
* Admin of AfterFive at af.itd.com 9999 128.160.2.249 9999 *
* "An unused CPU cycle is a wasted CPU cycle. You can't save them up!" *
******************************************************************************
Yeah, yeah, yeah, Standard disclaimer here. I do NOT in any way shape or form
speak for ITD, SRSC, NASA, nor any other organization. Everything contained
in this mail are my own personal thoughts and opinions. Flame away.
Christopher Davis
H> Can someone explain to me how a simple MUD chews up 80% of any given
H> data line faster then 9600 BAUD? Here are the stats for a MUD named
H> AfterFive. I've had between 15 and 50 users on at any given time.
H> AfterFive stats:
H> Up since: Fri Sep 18 16:34:46 1992
H> User time used (CPU secs)........6310.32
H> System time used(CPU secs).......1224.65
H> Messages sent via socket(s)......1880828
H> Messages received via socket(s)..332475
H> Folks, This is a TINY amount of data. I ftp more then that on an
H> HOURLY basis during the weekdays. Yet this is the usage for my MUD
H> less then 48 hours. I'm not trying to flame anyone. I just would
H> like to see HARD FACTS. NUMBERS posted when talking about resource
H> utilization with MUDS.
Ever heard of packet overhead? It's what makes VJ CSLIP such a win on
modems. Remember that over a telnet or rlogin connection, if the link
is not using CSLIP, there's about a 40 byte overhead PER CHARACTER from
the "terminal" side, as well as an equal amount back for every echoed
character. FTP traffic is usually in 512 byte blocks (or larger) and
therefore has a much smaller percentage of overhead.
Those 332,475 bytes of actual data represent about 13M of transmitted
data *each way* for the character echoing. A 56kbps line can transmit
about 6K/s at best.
Believe me, a bunch of interactive traffic can kill a line in no time.
--
Christopher Davis | ]CALL -151
<c...@eff.org> | *300: 20 DD FB 60
System Administrator| *3D0G
EFF +1 617 864 0665 | ]CALL 768
Petri Virkkula
Christopher> Nntp-Posting-Host: loiosh.eff.org
Christopher> Those 332,475 bytes of actual data represent about 13M of transmitted
Christopher> data *each way* for the character echoing. A 56kbps line can transmit
That would have been true with older muds which used telnet's
character-mode. However newer versions uses telnet in
line-mode.
Petri
--
-----------------------------------------------------------------------
Petri Virkkula | email : Petri.V...@hut.fi
J{mer{ntaival 11 H 168 | pvir...@niksula.cs.hut.fi
02150 Espoo | pvir...@nic.funet.fi
FINLAND | Phone : +358 0 455 1277
-----------------------------------------------------------------------
Joern Rennecke (guest)
>Ever heard of packet overhead? It's what makes VJ CSLIP such a win on
>modems. Remember that over a telnet or rlogin connection, if the link
>is not using CSLIP, there's about a 40 byte overhead PER CHARACTER from
>the "terminal" side, as well as an equal amount back for every echoed
>character. FTP traffic is usually in 512 byte blocks (or larger) and
>therefore has a much smaller percentage of overhead.
>Those 332,475 bytes of actual data represent about 13M of transmitted
>data *each way* for the character echoing. A 56kbps line can transmit
>about 6K/s at best.
>Believe me, a bunch of interactive traffic can kill a line in no time.
I can't speak for other muds, but at least with an Lpmud >= 3.0.41 ,
the server will request to enter line-by-line mode, with local echo,
so that the 'terminal' side will only transfer a single packet for each
command, which won't be transferred back;
and command response won't be sent unless at least 800 characters have
summed up, or command execution completed.
Thus, packet overhead is considerably smaller than the actually transmitted
information.
Amylaar
Scott Goehring
>Ever heard of packet overhead? It's what makes VJ CSLIP such a win
>on modems. Remember that over a telnet or rlogin connection, if the
>link is not using CSLIP, there's about a 40 byte overhead PER
>CHARACTER from the "terminal" side, as well as an equal amount back
>for every echoed character. FTP traffic is usually in 512 byte
>blocks (or larger) and therefore has a much smaller percentage of
>overhead.
Most muds run in line-mode telnet, not character mode. The overhead,
while not insignificant, is not nearly so large as you purport it to
be. 40 bytes per LINE of user input. No major variety of MUD uses
character mode anymore except in unusual situations (the vi mode hacks
on some LPs come to mind).
The socket code I wrote, and the code in TinyMUD, do buffering on
output to minimize output packets, so output is even more efficient
(usually you'll get MTU-sized packets on a semi-regular basis), so 40
bytes per ~1500 bytes of output (MTUs vary, granted).
>Those 332,475 bytes of actual data represent about 13M of transmitted
>data *each way* for the character echoing. A 56kbps line can transmit
>about 6K/s at best.
--
And why are we taking an oath of fealty to a piece of cloth, anyway? I don't
have any problem about defending my country and fellow citizens, but I don't
want to die for fabric.
-- Brent Chivers
...
>Can someone explain to me how a simple MUD chews up 80% of any given data line
>faster then 9600 BAUD? Here are the stats for a MUD named AfterFive. I've
>had between 15 and 50 users on at any given time.
TCP/IP is a connection oriented protocol. It may be that the site in
question had a limited number of connections and the MUD was using
them.
--
"Focus on winning and to hell with how you play the game."
#188 Life's Little Destruction Book
Christopher Davis
ckd> there's about a 40 byte overhead PER CHARACTER from the "terminal"
ckd> side, as well as an equal amount back for every echoed character
Scott> Most muds run in line-mode telnet, not character mode.
Last MUD I used (admittedly, quite some time ago) was set up as an
account's login shell, so it used telnet & rlogin. I'm glad they're
using line mode now, that does help quite a bit, as you noted.
Scott> The overhead, while not insignificant, is not nearly so large as
Scott> you purport it to be. 40 bytes per LINE of user input.
Yeah, but then, how long are these lines of user input? Probably
somewhere between 2 characters ("w\n") and 80 characters (in a "tell" or
the like). The overhead is, still, higher than the "raw" character
counts would appear (though not as high as I had originally thought).
Scott> The socket code I wrote, and the code in TinyMUD, do buffering
Scott> on output to minimize output packets, so output is even more
Scott> efficient (usually you'll get MTU-sized packets on a
Scott> semi-regular basis), so 40 bytes per ~1500 bytes of output (MTUs
Scott> vary, granted).
Good deal. Yeah, MTUs vary, and at least some TCP/IP implementations
will go down to 576 on any packet not going to the local wire. But this
helps a lot.
Andrew Molitor
>AfterFive stats:
>Up since: Fri Sep 18 16:34:46 1992
>User time used (CPU secs)........6310.32
>System time used(CPU secs).......1224.65
>Messages sent via socket(s)......1880828
>Messages received via socket(s)..332475
>
>Folks, This is a TINY amount of data. I ftp more then that on an HOURLY basis
>during the weekdays. Yet this is the usage for my MUD less then 48 hours. I'm
>not trying to flame anyone. I just would like to see HARD FACTS. NUMBERS
>posted when talking about resource utilization with MUDS.
>
>A little over 2 megs isn't much in my book...........
You *idiot*. 2 million messages, not 2 million bytes. Moron.
Andrew
>Howard
Ah.. now I see.