[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