Is there a way to remove the spam check? I would like to be able to paste lots of data into a writing buffer without being disconnected. Is this possible? I know that it could lead to abuse, but my server is so small that this is not a problem.
Writing Buffer Q?
Posted by Tux on Sat 12 Aug 2006 11:33 PM — 8 posts, 30,523 views.
I'd assume you can just search the code for the bug message and remove the ifcheck. But it's probably there for a very good reason.
That's what I have been trying to do. I haven't seen any type of bug message being sent out when this happens. It just shows a client being disconnected like a peer/ping timeout does, EOF bug() call. I understand that it is there for a reason, but sometimes I want to paste a large amount of data into a writing buffer, usually an ingame change, or a new ascii art for the motds and it disconnects me. I was hoping that someone had a fix or patch for this to disable this in a writing buffer or all together.
Are you talking about the spam filter that logs you off if you exectute the same command more than 20 times (look in comm.c for 'PUT A LID ON IT') or the buffer overflow thing that occurs if too much data is sent to your descriptor at once causing to you to be disconnected (not sure where you'd go about that right off hand)?
The buffer overflow, I assume.
In that case, my best guess would be that Tux would need to make his buffers bigger (MAX_STRING_LENGTH and/or MAX_INPUT_LENGTH) if it's happening when he's trying to input a large chunk of data. Now if the problem is when someone is trying to view that large chunk of data I'd be interested myself in finding out how to adjust that buffer max so that I could make certain large data files have less restrictions because I get that one all the time and usually have to just restrict the individual commands to limit how much data can be displayed. (Have that issue currently in a number of places.)
On the other hand, it might be worth noting that you want to be careful and not go overboard on how much bigger you set those two buffer limits because otherwise you'll run into the 2nd problem when the mud echos that data block back to you too.
On the other hand, it might be worth noting that you want to be careful and not go overboard on how much bigger you set those two buffer limits because otherwise you'll run into the 2nd problem when the mud echos that data block back to you too.
Personally I would be very wary about changing the buffer sizes, because you'd be opening yourself up to abuse from malicious players, not to mention that a lot of code assumes many things about those buffer sizes (e.g. without using proper constants).
MUSHclient at least can help you with this by sending very large chunks one line at a time, with a line every 200 ms or so, which will give the MUD server enough time to process stuff before filling up the buffer.
To fix this properly on the MUD server side would require a fair amount of work, because you would have to have it recognize that a buffer is full, and stop filling it up further until it gets a chance to process some of it.
MUSHclient at least can help you with this by sending very large chunks one line at a time, with a line every 200 ms or so, which will give the MUD server enough time to process stuff before filling up the buffer.
To fix this properly on the MUD server side would require a fair amount of work, because you would have to have it recognize that a buffer is full, and stop filling it up further until it gets a chance to process some of it.
yeah he is talking about the overflow, which i think can be annoying too, however i figured it was put in for a reason, but if you want to change it i believe changing the MAX_INBUF_SIZE inside mud.h is all you need to do, the default size from stock smaug is 1024.