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
__
distcc mailing list http://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc
