I don't think that using something like wait_state would work in this cause. Cause then all outgoing information would be held off. And it looks like you would end up eating CPU slowly feeding that buffer out. If you had someone with a horride connection. Get 100 players on in a fight and you will probly begin feeling it.
----- Original Message ----- From: "Hiddukel" <[EMAIL PROTECTED]> To: "ROM" <[email protected]> Sent: Tuesday, November 19, 2002 3:12 PM Subject: RE: Disconnects > If I'm not mistaken the code already allows for this type of buffering > via the scroll option. Basically what I am talking about is an > automatic paging system whereby the user need not send a carriage return > at the [hit return to continue] prompt, it would simply wait a pulse or > two and then continue the output, preferably without a prompt in > between. The pulse or two should in most cases allow the connection to > finish receiving some of the data before more is sent, basically slowing > the output down without affecting the performance of the mud. True the > mud will seem a bit slower because of the pulse wait in the output, but > given that we can control the rate of input using wait_state I don't see > why we can't control the rate of output in much the same way. > > This would seem to answer my own question, however I am not familiar > with how the wait_state works, only that it does work, so any > information that you could give me on how to add an output wait_state > would be much appreciated. > > Thanks, > Matt Bradbury > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of brian > moore > Sent: Tuesday, November 19, 2002 01:06 PM > To: ROM > Subject: Re: Disconnects > > <snip> > Your thinking isn't considering the whole problem. > > Yes, the telnet protocol allows for unlimited data (how else would you > maintain a connection for days). > > What it doesn't control is "when UserA issues a command that requires > sending more data than he can receive, how do we buffer all that data so > we can continue processing input and output for others until he's ready > to accept more data." > > Did you catch the keyword there? It's 'buffer'. > </snip> > > > > > -- > ROM mailing list > [email protected] > http://www.rom.org/cgi-bin/mailman/listinfo/rom >
