Re: [forum] About our effort at NoMachine

[Keith Packard <keithp@keithp.com>]

Around 1 o'clock on Mar 27, Gian Filippo Pinzari wrote:

> Yep. Keith Packard, if I remember correctly, seems to not agree
> on proxies being used as a long term solution,

Not on proxies in general, of which SSH is a good example, but only on the 
LBX proxy in particular which has the very bad behaviour of operating a 
request at a time which increases latency for large requests even further.

However, all of my measurements over DSL-style lines (<1Mb bandwidth > 
50ms rtt) show that bandwidth is not a significant problem, and that the 
dominant cost remains latency, even for image intensive applications like 
web browsers.

If done in a trivial manner, image caching will also introduce latency for
misses as the proxy will be forced to wait for the entire image to be
available from the client before locating it in the cache.  However, I can
imagine a clever cache which could recognise a miss early and start
streaming the image as soon as that was detected.

> They can finally leverage the cross-client recurrence of common X
> operations to achieve significant compression ratios.

LBX attempted this for some operations with limited success; server 
startup data and keymapping information could be supplied from the local 
cache.  I wonder how much additional data could be shared in this fashion, 
and again, if the effect is only to reduce data on the wire, the technique
won't be nearly as effective as one which could short-circuit the X server 
entirely.

> Proxies can efficiently multiplex the traffic, and optimize bandwidth usage
> according to the type of traffic being generated.

Seems like you're reimplementing TCP on top of TCP.  In my experience, TCP 
works pretty well without an additional multiplexing layer on top.  This 
was one of the significant problems in LBX as large requests could 
monopolize the wire for a long time.  Using one TCP stream per client 
means each client gets a fair share of the network bandwidth.

-keith