some explanations about architecture

This commit is contained in:
amit bezalel 2017-07-15 08:09:52 +03:00
parent 947ef9d970
commit adee751f0e

View File

@ -16,8 +16,16 @@ but the code is already working (see server_test, proxy_test & player_test)
![Image of Arch](https://github.com/amitbet/vncproxy/blob/master/architecture/proxy-arch.png?raw=true)
Communication to vnc-server & vnc-client are done in the RFB binary protocol in the standard ways.
Internal communication inside the proxy is done by listeners (a pub-sub system) that provide a stream of bytes, parsed by delimiters which provide information about RFB message start & type / rectangle start / communication closed, etc.
this allows for minimal delays in transfer while retaining the ability to buffer and manipulate any part of the protocol.
For the client messages which are smaller, we send fully parsed messages going trough the same listener system.
Currently client messages are used to determine the correct pixel format, since the client can change it by sending a SetPixelFormatMessage.
This listener system was chosen since it allows the listening side to decide whether or not it wants to run in parallel, in contrast having channels inside the server/client objects which require you to create go routines (this creates problems when using go's native websocket implementation)
**Player**
![Image of Arch](https://github.com/amitbet/vncproxy/blob/master/architecture/player-arch.png?raw=true)
The code is based on several implementations of go-vnc including the original one by Mitchell Hashimoto, and the very active fork which belongs to Vasiliy Tolstov.
The code is based on several implementations of go-vnc including the original one by **Mitchell Hashimoto**, and the very active fork which belongs to **Vasiliy Tolstov**.