Command stacking

Between me and a few people talking, we brought up the idea of being able to clear stacked commands on a SMAUG ( well, SWR, but for these purposes, same thing ). Now, as I follow the process, this happens: A person sends a command from their client to the host machine. This machine, using port info, routes it to the open file descriptor associated with the processes PID. When the mud reaches the point where it checks for new commands, it will try to read in from the appropriate file descriptor. If there is nothing there, it doesn't do anything, like the character was idling. If there is something there, then it read it in and adds it into d->inbuf, where it can later be processed by interpret.

Now, most of this that I cam going off of if in read_from_descriptor. The tricky part, I think, is that the mud checks if there is a pending command to finish before reading in the next one. So, for example, if their last command hasn't finished, because of a wait state for example, it will not read in from the file descriptor. No, I understand that this probably was intended to stop overflows of buffers, which makes sense.

Now, if someone has a wait state, for example, they can stack multiple commands, and these stay in the file descriptor, not the mud. So, what we want to do is check if a specific phrase has been entered ( "clear" by its self, for example ), and if so, flush the file descriptors buffer.

We have thought of a few ways, but not sure if/how they would work properly. One was to read everything in all at once, check through it for the clear command, and if its not there, write it all back, stripping off the begining line, of course, as this is the next command. If it is there, then just dispose of all of the infomation, effectively flushing it.

Another thought was to use fseek, or something similiar, to try to find the phrase, and use rewind to put it back if its not found, or everything after it is found.

Any thoughts, or maybe something like this has been done, and a lot more simply than described above?

I strongly doubt you can "put it back" into a TCP/IP connection. It wouldn't make much sense to allow that.

Your other approach may work. Without looking at the exact code, what it must do is break up the incoming text stream into commands, basically delimited by a newline. When a newline arrives (which it might not in a particular packet) that command can be processed and the rest kept for next time.

What you could do is, rather than processing each command as you reach a newline, is make a list of them (a linked list say). You may well have an unfinished one at the end of this list (ie. no terminating newline).

Then walk the list looking for "clear" and if you find it, discard everything up to and including the "clear" and then repeat the process in case they did "clear" twice. Finally take what is left and start feeding them through the command interpreter.

Of course, you need to allow for, next time through, this list may be non-empty.

I think the flowchart would be roughly:

1. Take input from the MUD, if there is a newline, you have a command. Add this command to the pending commands list.
   
2. Repeat the above step until no more newlines are in the input stream.
   
3. Now examine the command list (this may have left-over commands from a previous time through this). Probably the simplest thing would be to go through it *backwards* looking for "clear". If found, delete everything in the list prior to, and including, the "clear" command. By going backwards you get the most recent "clear".
   
4. With whatever commands are left over, take the first one and process it. (The others will be done next time through the loop).

I was very intrested in this, but couldnt think of a good way to do it. If you guys work somthing up it'd be much appreciated if you post it up.



Spike