[Lcdproc] Increasing the server's receive buffer

[Andre Guibert de Bruet]

On Mar 3, 2009, at 5:17 AM, aeriksson2 at fastmail.fm wrote:

> bsdfan at nurfuerspam.de said:
>> Looking harder at the server I found that LCDd indeed loops when  
>> reading
>> from the client as long as data is available, but *only* if the  
>> client  does
>> not send more than 7K. The loop is part of sock_poll_clients().
>
> I'm obviously missing something. Can anyone share why the server and/ 
> or client
> uses, or is supposed to use, tcp's message interface? Why doesn't it  
> read the
> data straight into the parsing buffer as most other code do these  
> days?

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.

> 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.

Cheers,
Andy

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */