[Lcdproc] Increasing the server's receive buffer
aeriksson2 at fastmail.fm
aeriksson2 at fastmail.fm
Wed Mar 4 13:59:45 UTC 2009
http://lcdproc.sourceforge.net/docs/current-dev.html
Hi Joris,
joris at robijn.net said:
> Hi Anders
>
>> I'm just concerned with how the TCP layer is
>> used by the LCDd server and lcdproc client.
>
> I think your'e right the handling of incoming data could be done better on
> this point. It's simply choking in a big lump of data that it cannot handle.
Now, _why_ does it do that? Reading the protocol spec, no command should be
bigger than one line... Or? Or is the problem that a client passes >8KB lines?
> Someone wrote about a modification with a second buffer, I think he's right.
> It's been a long while since I had a look at that code, I vaguely remember
> what it looks like.
>> Is there a formal writeup of the LCDd protocol somewhere?
> Check the online manual on the documentation page. It's generated from
> docbook documentation.
Is http://lcdproc.sourceforge.net/docs/current-dev.html, chapter 3, the right
place to look?
> There's no telling what the server does after the first two steps. Will it
> display the partially defined screen? A way to turn this into an atomic unit
> would be to wrap it in "start" "stop" statements.
> The protocol was meant to be used by very simple clients as well. If they do
> no return checking things should work (a bit). It was never meant to be
> atomic. It's just a (too) simple implementation of handling incoming data.
Sure, I can see where it's cominging from, but as it currently stands, it's
impossible to create a bug free client from it.
Would it be useful if I review and comment ch3 and we'll work out what the
weaknesses (spec and/or code) are?
Rgds,
/Anders
More information about the LCDproc
mailing list