Current applications are analyzed to judged the efficacy of the techniques used by LBX to improve X performance over low-bandwidth/high-latency network links. The results show that LBX fails to substantially improve performance largely because of it's requirement to provide compatibility with the X wire protocol. The historical context of the development of LBX has also burdened it with the replication of a significant amount of network infrastructure making it both overly complex and less efficient on the wire.
LBX was designed to ameliorate the effects of limited bandwidth and high latency network connections on the execution of X applications. It was based on the simple X compression work done by Network Computing Devices (Xremote) and Tektronix (Serial XPress).
Both of those protocols focused only only compressing the X bytestream using relatively simplistic techniques. As they were developed in an era before the widespread adoption of serial-line IP technologies (SLIP and PPP), both also provide for the multiplexing of many X applications over a standard RS232 link.
LBX was an attempt to analyze the successes of these two implementations and develop a standard incorporating the best of them along with new technologies. The most important new ideas were in reducing the effects of higher network latency. However, without changing the internals of applications, the areas where LBX can have effect are rather limited. LBX provides for short-circuiting in pixel allocation and window property data transmission between clients. It also caches Atom names to reduce round trips when multiple applications intern the same Atom name.
X applications have usually been developed in a high-bandwidth/low-latency environment, either entirely within a single machine or perhaps over a local area network. Such environments exhibit bandwidth in excess of 1MB/sec and latencies less than 1ms. Moving applications to serial lines decreases the bandwidth by more than a factor of 100 and increases latency by a similar amount.
Relatively simplistic analysis of X protocol traffic from current and older X applications demonstrates that while limited bandwidth has an effect on application performance, the largest effect comes from large network latency usually present in low speed network links.
While version 11 of the X protocol was designed to allow for asynchronous operation for almost everything, application development often takes advantage of the relatively low latency provided by local or intra-computer networking. Applications make frequent requests for data which could easily be computed or cached. Xlib doesn't provide easy access to the underlying asynchronous nature of the protocol forcing additional synchronization points during application execution.
The effect of additional synchronous communication is most evident during application startup; applications which start in less than one second over a local network can take tens of seconds to start over a modem link. Much less important are the smaller effects which occur during program operation as application feedback latencies of less than 50 to 100ms are not generally visible to the user.
To assess the value of the various LBX network optimizations, application startup data were collected and analyzed to determine which operations would affect startup times most significantly in the presence of a low-bandwidth/ high-latency network link. What became evident was that while the techniques present in LBX might help somewhat, the overwhelming performance problems were caused by application and toolkit misfeatures that couldn't be easily masked outside by an X protocol proxy.
Interpretation of the application behavior lead to a set of simple application and toolkit recommendations which would improve performance in all networking environments. Such changes would not have the detrimental effects of LBX in using a proxy while providing nearly all of the benefits.
The only useful changes to the wire protocol are the use of lossless image compression within X or a full wire-level compression proxy such as SSH underneath X. Again, these could be implemented without the addition of a separate proxy agent.
As LBX is only able to slightly improve application performance over slow network links, there has never been a significant effort to widely deploy it. However, given the ability to modify the toolkits used by X applications, the underlying performance problems can be fixed with relatively modest changes providing better performance than LBX could offer while avoiding the complexity of an external proxy agent.