Protocol compression

Harco de Hilster harcoh "at"
Fri, 13 Mar 1998 15:37:43 +0000

Quentin Stafford-Fraser wrote:

> We like the idea of adding compression, and something like LZO seems to be
> the way to go.

I took a very quick look at LZO. It is assembler disguised as C-code, fullof beautiful pointer arithmetic, gotos, macro expansions
etc. Not something
you easily port to java.

The fact that zlib is supported by a lot of different parties and adopted by
JavaSoft (included in Netscape 4.03), is in my opinion more important  than
the higher speed of LZO.

> The protocol has always been built on the concept of negotiating encodings
> upwards; ie. the only assumption made is that the client can draw raw
> pixels. The easiest thing would probably be to add 'compressed raw' and
> perhaps 'compressed hextile' as new encodings which could be selected like
> the others if the client supports it

All current and future encoding schemes could benefit from additional compression,therefor a separate rfbSetCompression message
would be more logical. This message
could include the compression type (zlib,lzo),  the compression scheme and
the compression level. The server should be allowed to refuse a request for compression.
It might even be useful to change the compression on the fly, just like you can change
the encoding.



Harco de Hilster  CAOS/CAMM Center       Phone:  +31(0)24-3653379
Research &        University of Nijmegen Fax:    +31(0)24-3652977
      Development Toernooiveld 1         E-mail: harcoh "at"
System Management 6525 ED Nijmegen       URL:
                  The Netherlands