On Tue, Nov 19, 2002 at 05:57:12PM -0500, Hiddukel wrote: > While I agree that bandwidth is the rate of output and I agree that you > can not easily increase the bandwidth between all clients and the > server, you should be able to decrease it relatively easily though.
(muttering about people who send private replies, get private replies, and then post to the list... make up your mind.) What purpose would decreasing the bandwidth serve? > Page_to_char works with a buffer from what I've seen, and sends the > client a number of lines, the number of lines is set by the player using > the scroll command. Why if you can stop the output in it's tracks and > it doesn't affect the rest of the mud can you not send a page, wait a > pulse, send another page, wait a pulse etc...? In effect you are slowing > down the rate of output or cutting the bandwidth required between the > server and client. 'In effect', sure. But that's what a buffer -is-. You fill up the buffer on one end and send data from it on the other end. A FIFO. You don't need to magically delay things. The MUD already drains the buffer as the client is able to accept data (ie, as the client sends ACKs on received data). It -must- do this to account for sending piles of combat data to a guy on a 14.4 dialup. > I did not mean to make the assumption that > wait_state itself could be used, what I was trying to do was make an > analogy to the fact that a wait_state controls the rate of input, it > does not ignore commands sent during the wait_state, it buffers them and > executes them after the wait_state is up ... why then could the output > not work similar to this? It does already. See page_to_char. See send_to_char. See write_to_descriptor. > I would also like to add that a denial of > service is not a concern when you are sending output not based on > anything other than a wait that is not determined by the client, in > order for a DoS to occur the client has to have some control over the > rate out output, in this case it doesn't, if it ignores the data sent > from the server the server is still going to send the rest of the data > of flush the buffer, it will just send the data slower than it would > without the output control. The client has total control over rate that it accepts data. If it does not send an ACK for a packet, it will stay on the server as will subsequent packets (well, ignoring Nagle, but even that will only send a few packets beyond what has been ACK'd). The way that the MUD is able to prepare data to be sent in chunks, whether it is TCP packets (your MTU is almost certainly no greater than 1500, yet MANY commands send more than 1500 bytes) or multiple pages of stuff sent to page_to_char is... buffers! The reason the link is dropped is because the buffer is full. Increase the size of the buffer if you don't want that, but, again, limits are a good thing: you will have to determine the balance between the acceptable size of the buffer and the loss of RAM as well as the latency in many connections being dropped. (ie, user unplugs ethernet cable, how long does it take before sending buffers are too full of unack'd packets before the connection is deemed unusable?)
