In <user-8ce088227264@xymon.invalid> Adam Goryachev <user-92fd6827f6ae@xymon.invalid> writes:
Henrik St�rner wrote:
It requires a new hobbitd daemon on the server side, and a new
"bb" utility at the client. Compression is not turned on by
default - you'll have to invoke "bb" as "bbz", or pass it the
"--compress" option.
Sorry to continue this conversation, but I'd like to clarify some
implementation details.
If I have two hobbit servers, and one bbproxy server which transmits the
data to both hobbit servers, and of course multiple bb clients behind
the bbproxy.
Do I need to update *both* hobbit servers, or could I only upgrade one
hobbit server, and the bbproxy, and bbproxy would be capable of
compressing received updates, and forwarding them to the compression
capable server, and forwarding the uncompressed updates to the older server?
You've caught one of the "missing items" in the development version -
bbproxy hasn't been made compression-aware yet. In the end, there will
be a way of specifying whether bbproxy target servers can handle
compression or not - so yes, you could have updates sent in compressed
form to one hobbitd, and uncompressed to another.
At least, that's the plan. I haven't looked too much at the
implementation details yet, so it might turn out differently.
Also, how do old hobbit clients, or bb windows clients, or hobbit
windows clients behave when behind the bbproxy? Would I need to upgrade
each client for it's updates to be compressed, or will bbproxy handle
that for me?
If a target server supports compression, then I think bbproxy will
perform the compression on all of the "large" messages, i.e. status-
and client-messages. Other messages are too small to be worth the
trouble of compressing them. So that will be transparent to the
client.
Regards,
Henrik