It seems like there'd be some way to flush the buffer when it gets full
instead of just increasing its size.. I don't know, I haven't looked at it
that much.
On Tuesday 19 November 2002 01:44 pm, Ammaross wrote:
> Actually, it isn't the client at all. It is in a little function known
> as write_to_buffer(). Check it out:
> if (d->outsize >= 32000)
> {
> bug("Buffer overflow. Closing.\n\r",0);
> close_socket(d);
> return;
> }
>
> If you check your logs, you'll probably find some of these. Up your
> '32000' value to maybe...1000000 (give or take) and you'll probably be
> fine for a while. ;P
>
> Ammaross Danan
>
> <snip>
> The problem is that your client can't handle all of the information
> being sent
> to it's buffers, so it's disconnecting you. The same problem will pop
> itself
> up if you are stuck in a fight that dumps a ton of lines of information
> to
> your client.
>
> On Tuesday 19 November 2002 11:50 am, Hiddukel wrote:
> > I have been having a problem for some time now, I've tried everything
> > I can think of to solve the problem but all I end up doing is working
> > around it for a while and then it shows itself again in other places.
> > My problem is that I am being disconnected whenever a large amount of
> > data is sent to me by the server. The first place I noticed it was in
> >
> > alist. I changed the alist command so that it takes arguments for the
> >
> > start vnum and end vnum of the areas you want listed. This works ok
> > except if you do alist 1 100, then it disconnects you because it's too
> > instead of just increasing the buffer size.. I don't know, I haven't
looked at it.
> > much data. I know that I can set my scroll value to something other
> > than 0 and it will page to me and not disconnect me, but this is also
> > a workaround. My thinking is that since ROM uses the telnet protocol
> > (and I've never been disconnected from telnet due to massive amounts
> > of data being sent to me) then there should be some way to fix this.
> > Any help on this matter would be greatly appreciated.
> >
> > Thanks,
> > Matt Bradbury
>
> </snip>
