Treker wrote:
>
> 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.)
> 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)
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.
> 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.
> 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
+------------------------------------------------------------+
| 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