[Xcb] [Bug 4232] xlsclients much too slow over network

[Peter Harris]

Josh Triplett wrote:
> On Wed, Sep 02, 2009 at 11:49:08AM -0400, Peter Harris wrote:
>>  - This version uses more bandwidth. This is an intentional trade-off in
>> order to reduce the number of round-trips. For example, this version
>> issues query_tree in parallel with get_property(WM_STATE), and then
>> throws the subtree away if the window does turn out to have a WM_STATE
>> property.
> 
> Without knowing a lot about how xlsclients works: why throw that
> information away rather than using it?

[This is about how XmuClientWindow works, rather than anything in
xlsclients per-se]

Once you have found WM_STATE, you don't need to dig any deeper to find
the one window with WM_STATE on it. Therefore, if you have WM_STATE, the
list of subwindows to further search for WM_STATE is useless.

It occurs to me that this version, despite sending more requests,
actually uses less *total* bandwidth than the old version. When Xlib is
waiting for replies one-by-one, each 32-byte request or reply is wrapped
in 18 bytes of Ethernet, 40 bytes of TCP/IP, mumble bytes of PPP, etc.

>>  - Shrink the string property request limits from 1MB (default lifted
>> from Xlib) to something more sensible (1kB, maybe? 100 bytes?).
> 
> On my system, the manpage mentions a -m option to set the maximum
> command length, which defaults to 10000.  Does that help?

No, because it was only ever used to clamp stdout, not the get_property
request, and I didn't change that.

In practise, it doesn't matter, because nobody ever has a 1MB command
line / window name / icon name / etc. In theory, it could be a DoS to
create windows with huge properties (but there are already so many ways
to DoS an X11 server you are connected to, what's one more?)

>>  - Optionally operate in near-synchronous mode, which would reduce peak
>> memory usage at the cost of extra round trips.
> 
> If you wanted to go this route, the right approach seems like putting an
> upper bound on the number of requests in flight.  That doesn't seem
> worth doing to me, though.

Nor to me, which is why it was left as an exercise for the interested
reader. :-)

Thanks for looking.

Peter Harris
-- 
               Open Text Connectivity Solutions Group
Peter Harris                    http://www.opentext.com/connectivity
Research and Development        Phone: +1 905 762 6001
pharris at opentext.com            Toll Free: 1 877 359 4866