[distcc] Proposed distcc protocol change to support caching

[Jake McGuire]

On Feb 13, 2006, at 5:28 PM, Dan Kegel wrote:
> We're prototyping adding caching to distcc/distccd.

Excellent!

> distcc protocol version 3 would have the client
> send a new packet, OPTS, after the DIST packet.
> OPTS would encode options as bits in the 64 bit argument.
> The following option bits would be defined:

*snip*

Summary: Why not aim higher?  Protocol changes happen infrequently,  
or at least they should, so if we can stick in some other stuff that  
we think is going to be useful down the road.

Details: Why use a binary encoding?  Network traffic at this point is  
pretty cheap, especially one-way data, as is the minor amount of CPU  
time to process some text.  Bitfields just add the potential for  
endian screwups and make some sorts of processing more complicated.

How about:

Commands starting with '?' are optional, and require ack/nack.  Like ? 
HSH for hashed source code.

Commands starting with '+' are optional and should be silently  
ignored if not supported.  Like, say, if someone wanted to make  
distccd report statistics like cache hits, or wanted distcc to flush  
the object cache

Also... not sure what your build traffic looks like, but it's  
probably worthwhile to put a placeholder in the cache when  
compilation starts so that if there's a "hit" it only gets compiled  
once.

-jake