[Lcdproc] Increasing the server's receive buffer

[aeriksson2 at fastmail.fm]

andy at siliconlandmark.com said:

> Though DMA-like systems are used where performance is critical, these   types
> of systems are often inflexible and of limited functionality in   a networked
> environment. Think of it this way: Besides host-specific   zero-copy sockets,
> what use is DMA on a network? TCP allows the source   of the data to be in a
> geographically separate area (It could be in   outer space, literally), or
> not, from the system running LCDd.

We're not talking about the same thing. I'm not concerned with the IP layer 
(e.g. fragmentation/reassembly). I'm just concerned with how the TCP layer is 
used by the LCDd server and lcdproc client. Or, to put it more succint, how 
the LCDd protocol interacts with the tcp layer. Is there a formal writeup 
of the LCDd protocol somewhere? I've only seem some howtos on how once _could_ 
write clients LCDd would understand. That's far from a formal spec and, to be 
frank, what I've seen lacks quite a bit from a protocol quality point of view. 
I'm hoping that there is a better writeup I've not yet discovered.

>> The only answer I can come up with is that you might want "create  
>> screen + define its content" to be an atomic operation.

> This is a good idea, but for the operation to be truly atomic, it   would
> have to fit in exactly one ethernet frame and not cross any   routers where
> it might get fragmented. Otherwise, you stall waiting   for more data until
> you get the expected number of bytes, which is the   design we have,
> presently.

>> Is that defined anywhere? If that's indeed the case, maybe explicit  
>> barriers in the protocol would be more stable.

> I don't follow. 

Today, we roughly do on the tcp pipe (not having the howto handy):
screen s <args>
widget s w1 <args>
widget s w2 <args>
...


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.

screen_def_start s
screen s <args>
widget s w1 <args>
widget s w2 <args>
...
screen_def_stop s

Only after having received the stop command would the server act on the wrapped 
commands. That would make the atomic units controlle by the client and, do so 
by dint of the application layer protocol (i.e. not relying on aspects of the 
transport (tcp), e.g. the message interface).

But the first order of business is to find a good protocol spec for the 
existing sitaution. Is there one?

/Anders