> > Hi! I'm new to the list, but my handle is Treker (yes, that's
> with only one
> > k)
> >
> > Anyhow, I've noticed that the actual code for Circle is rather...well,
> > overcomplicated (not so much as sloppy, just full of itself).
>
> Most programs that are aged, and have 35K lines to them have interesting
> quirks, if you see the size of some cod bases out there you'd be even
> more scared (currently I've got a mud with about 80K lines in it, that's
> what you get for having oasis, dg scripts and other strange things
> around, and because I inheritied it I've seen some interesting things in
> it.)
Yeah, I've already had to rewrite some netscape code to customize the
browser for a friend's company (and to remove a few vulnerabilities), so
I've seen code with megs in it. It IS scary.
>
> > 2. I'm starting to code a new MUD, and am now working on
> improving a buffer
> > overflow crash in Circle, the MUD crashes when it attempts to
> send over a
> > certain amount of data through a socket to a user. The idea here is to
> > prevent flooding by either enlarging the output buffer, setting
> up a queue
> > of data, creating a ratio maximum output (ie: 100 lines per
> minute max), or
> > some other arcane means. There are several problems with this.
> >
> > a. Enlarging the buffer will make it harder but not impossible.
> > b. Setting up a queue of data, after which when it is full the user will
> > receive a "Please Wait" prompt of some sort, would probably
> interfere with
> > many automated "return" scripts, such as those in zMud's mapping system.
> > c. Ratios would definitely limit the users movement, and should not be
> > implemented purely because they remove the user from the
> atmosphere of role
> > playing and force him/her to deal with computer issues at the same
> > time--besides, what's all this modern technology if we can't
> use it to its
> > potential--speed.
> > d. I've a feeling how inetd does it, but buffer overflow handling isn't
> > something I'm about to explain on the list right now.
> >
> > If anyone has any ideas, please share!
>
> I've never seen this problem, I believe that bpl 17 has a patch to
> improve this. And it'll probably turn up in bpl 18. However the effect
> isn't to crash the mud but to just disconnect the player:
> http://www.circlemud.org/~greerga/newsocketcode.comm.c.diff
>
> (note it might not be a clean patch in, I'm not sure if that's the bpl
> version or not)
Okay, user sends the word "commands" to the server many many many many times
very quickly, entire mud crashes. Not just user disconnected. But this
only happens after the MUD frantically sends about 30 full output replies to
the command (the help screen listing commands). Like I said, it'd only be
a temporary fix to increase buffer size.
This has caused much trouble on 4dimensions.org, which has this bug. I
tried it on one of the bpls (was between 13-16) and it worked, Mud crash.
I'll check out that patch.
>
> Or are you talking about the problem of:
>
> int i, x = 0;
>
> for (i = 0; i < 200; i++) {
> x += sprintf(buf + x, "some really silly amount of text
> 12345789012345678901234567890123456789012345678901234567890");
> }
> send_to_char(buf, ch);
>
> which of course will overflow the size of buf. The simplest fix in this
> case is to add a check that x < (size_of(buf) - (size of a line)) Ok
> you don't output everything you wanted, but you output a fair amount.
> Or you could make it do a sprintf, then do the send_to_char on each
> line.
No, that's not what I'm talking about. However, that might also crash the
MUD, I don't know--haven't tried.
>
> > For now, the best plan would be to set up a larger buffer (a
> good several
> > decakilobytes larger).
>
> That would work for a while, but it'd be overkill for most functions,
> and given enough stuff to output you'd still fill buf.
As I said above: > > a. Enlarging the buffer will make it harder but not
impossible.
>
>
> > I propose that any future releases of CircleMUD should have
> larger outgoing
> > buffers, maybe the next power of 2 until the developers (you too, Greera
> > =) ) get a better idea for error correction/crash prevention/buffer
> > maintainence.
>
> I believe that this isn't an issue with stock circlemud, it's only with
> extensions, eg I suddenly have 200 levels to show in the level command,
> not 34, so the buffer overflows, having global buffers is known to be an
> issue, I believe that george did some work on having buffers allocated
> when you need them, it's available from his area on the web:
> http://www.circlemud.org/~greerga/buffer/
>
> Chris
Not related to the problem, sorry.
The problem implies abuse by the user/player.
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT