|Site sponsored by IGEL|
Voodoo - The network transparency layer of DirectFB
The recent development of Voodoo enables DirectFB applications to run over a network connection without modifications.
The concept is quite simple and working great. Each interface has two new implementations: "Requestor" on client side and "Dispatcher" on server side. Between them is a very small libvoodoo which manages network connections and provides fast and powerful message encoding and decoding.
Each Dispatcher instance gets an ID which is also managed by libvoodoo. The Requestor sends a request message for each method call, specifying the remote instance ID and the method that is to be called. Parameters are appended to that message before it gets sent to the server. On the server side the Dispatcher interface is looked up in a hash table using the instance ID. After fetching the parameters from the message without copying any data except for some rare cases, the Dispatcher calls the "real" implementation.
Some requests have a corresponding response and some don't, e.g. all drawing related methods return immediately after sending out the request. Methods that require a response block until the response is received. Each response contains at least the result (DFBResult). Further response data is appended to the response message and returned to the application after being processed by the Requestor.
Not every Dispatcher is server side and not every Requestor is client side. IDirectFBEventBuffer and IDirectFBDataBuffer have a client side Dispatcher and a server side Requestor. The server has to send events to the client side by making a PostEvent request (without response). It also has to fetch data via requests to the client side data buffer (with response), e.g. while it is dispatching a RenderTo request. The client will send its compressed data (PNG for example) over network to the server!
Another advantage is that existing applications can be used without changes.
The setup is quite simple: There's a new program called "dfbproxy" which just waits for incoming connections (currently port 2323). It doesn't even call DirectFBCreate() before clients request that.
Running applications via the proxy is done by passing "--dfb:remote=<host>".