Rom... BOOT?
 

Is the code that boots someone if they enter large blocks of text part of ROM, or is that my own server being whiney? I've played some mushes that allow ridiculously huge blocks of text entered for emotes, descriptions, building etc and have to have it! I don't know how many times I've been disconnected while writing a long note or some such... if it is ROM, what should I be looking for?

Edit: I do know about the "Line too long." code, and I don't mean that... I think. It's different from the disconnect I'm looking to change.

Re: Rom... BOOT?
 

What client are you using? It's entirely possible your client is the protester in this situation.

However, if you're writing a long note and being disconnected during the process, it's likely that you're idling out. When you're writing via in your client, no data is actually being exchanged between you and the mud. It's most likely that it's your ISP shutting down what it considers an idle connection. I'm guessing ROM will detect that you're in a mail editor and assume that you're active while you are.

My suggestion would be to write in an offline editor while you remain active on the mud even if it's hitting enter every now and then. Then pasting the mail when it is fully written into your mud client.

Re: Rom... BOOT?
 

I use mushclient.

The booting occurs when I enter the large block of text, not while writing it. And I'm 100% sure it's not my client because on mushes I don't suffer this problem.

This disconnect is a cause of input flooding, and I don't know if it's the server rejecting large packets, or the mud, I figured it was the mud because it happens on all ROM muds I've played, though I don't have a lot of experience with other types of mu*s.

Re: Rom... BOOT?
 

IIRC in write_to_descriptor() ROM checks for an error after the call to write() and if it receives an error returns a value that ultimately causes the socket to close.

The code is not checking for the special error case of EAGAIN which basically means "You tried to perform an action on a non-blocking socket that would have blocked", or the short version, "Not yet!".

You'd need to check for this error and, combined with how much output actually DID get sent, adjust the buffers accordingly then try again on the next pulse of the MUD. After a certain amount of pulses you'd probably want to just give up.

If you have the ability to run a copy of your mud on a local server with no network latency, chances are you don't see the error at all because you are able to receive the data as quickly as the MUD is able to send it.

Re: Rom... BOOT?
 

That's the wrong end of it. That kills a connection when the OS won't take all of the mud's *output* in one go. The code dates all the way back to Diku, if you're interested. Machines had little memory to spare when Diku was developed, and they weren't about to waste it doing all kinds of caching for spammy players on slow connections.


OP: Most games just truncate very long lines of player input. I'm not sure why a typical ROM would just kick you like that, but have you examined the log file? ROM's usually logs *something* when a connection is made or dropped.

Re: Rom... BOOT?
 

You're right, my mistake. Completely misread the original post. He was referring to large amounts of input.

Re: Rom... BOOT?
 

Some fun testing led me to find that 1015 characters worth of input get me booted, and a quick look at the logs reveal the boot occuring in this loop in read_from_descriptor:

for (;; ){
int nRead;
nRead = read(d->descriptor,d->inbuf + iStart,sizeof(d->inbuf) - 10 - iStart);
if (nRead > 0){
iStart += nRead;
if(d->inbuf[iStart-1] == '\n' || d->inbuf[iStart-1] == '\r')
break;
}
elseif(nRead == 0){
log_string("EOF encountered on read.");//right here!!!<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
returnfalse;
}
elseif(errno == EWOULDBLOCK)
break;
else{
perror("Read_from_descriptor");
returnfalse;
}
}

This is stock code, as I am not comfortable messing with sockets and core I/O, so this should be in most other ROM too...
Edit: Also... rats on it not saving the spaces...

Re: Rom... BOOT?
 

Just as an additional note, this problem may also fall at the feet of some clients. I know that no matter what mu* I am playing on, if I enter a block of text more than a page in length (such as copy pasting new scripts), jmc will crash flat out. I've tested several clients, and I did find a handfull that didn't have this problem. Though knowing little about what makes the clients tick, I haven't the slightest idea why. I am guessing that there is also a similar problem with many code bases as well. It's funny that nobody has come along and fixed the problem by now.

Carry on

Brawny

Re: Rom... BOOT?
 

If read() returns zero, your client has asked to disconnect gracefully.

But, 1015 characters is 1 past 1024, which most likely the size of d->inbuf, minus the 10 you see in the code there, which is a big coincidence.

Hmm!

Re: Rom... BOOT?
 

Earlier than that, even:

When this particular function returns FALSE it causes the parent to close the socket. IMHO this is pretty poor behavior, especially for a mere 1015 character limit. ROM's ancestor Diku seems to handle it much more gracefully, truncating long lines.

Re: Rom... BOOT?
 

I don't know why, but that error message doesn't pop up, only the one from the block I listed.. so either that block doesn't work or the one I posted calls sooner?

Edit: I increased the size of inbuf to MSL and it is a happy camper now.