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>
