Finishing the network protocol
ahartmetz at gmail.com
Sat Mar 19 14:23:41 PDT 2011
So, I've gone ahead and implemented my ideas as a proof of concept.
I still hope that my work can be adapted and integrated into the official
Wayland. I have a lot more experience with network protocols than with X11 and
OpenGL and friends, so this is what I can do to help Wayland.
I have already described the problems, here is the description of an
implemented solution. Please respond with any comments or criticisms. I won't
explain too much here, I've done it before and I've basically just tried to
solve existing issues with the smallest amount of changes.
- Per client ID spaces, except for global objects
- Separate server and client ID spaces: clients requesting object creation use
positive IDs, the server uses negative IDs, global objects (always created
by server) use a sub-range of negative IDs.
This prevents ID clashes between server-initiated and client-initiated
- When an object is destroyed, all parties that know about an ID must confirm
that they know about its destruction. Only then can the ID be reused without
risking ambiguities due to the asynchronous nature of the protocol.
(If a client disappears it is assumed that it confirmed all pending
destruction events and sent destruction requests for all other objects.)
- When a global object is created all clients are informed via the
display::global() event and it is assumed that the clients created the local
counterpart and are listening to its events. To avoid unnecessary wakeups,
clients can either "choke" the server, i.e. tell it to stop sending events,
or if they are permanently not interested they destroy the object and tell
the server about it. They cannot re-subscribe in that case, due to ID
ambiguity issues. The object is not destroyed on the server even when zero
clients have counterparts so that a client that is added later can still
When the server destroys a global object the usual rule applies that all
clients must confirm its destruction before its ID can be reused.
The choking mechanism could be extended to all objects (i.e. including non-
globals), but just creating or destroying the object as required seems
I have picked the term "choking" because it is also used in the widely used
- There is a remoteDetached() virtual method on objects that is called when
the remote side has destroyed the object or disconnected altoghether.
This will mostly be used to destroy the local objects in response,
- Implementation details: objects are linked to a class implementing the
IConnection interface. Connection is the usual implementation, and only
global objects in the server-side implementation use the BroadcastConnection
class that contains more involved logic to handle the one-global-server-
I'll be available by mail and on IRC to answer detailed questions in case you
can't be bothered to read C++ code - it seems that most C programmers don't
like C++ and vice versa...
The repository homepage is at
clone URL is
More information about the wayland-devel