Hello, I think I can do the second point in the TODO file: The message format has to include information about number of fds in the message so we can skip a message correctly. Or we should just give up on trying to recover from unknown messages. We need to make sure you never get a message from an interface you don't know about (using per-client id space and subscribe) or include information on number of fds, so marshalling logic can skip. So one solution is to include the number of fds in the serialization of the message, maybe as a 3rd word in the header? The idea about subscription also sounds reasonable, but I don't understand what is ment by "per-client id space". After a global object is broadcasted, the client may choose to subscribe or not, but I don't see per-client id space here (except that the server must maintain for each client what ids is he listening to -- maybe that is meant by "per client id space". Also, somewhat related, how different versions of the same interface are going to be handled. For example a client only "knows" version 2 of Foo, but the server broadcasts version 3 of Foo at some point. So does the client subscribe? What if Foo's messages are crucial for that client? Maybe it should specify ver 2 in the subscription, and then the sever must make sure not to broadcast messages that are not included in ver 2, but then ver 3 must be backward compatible I guess. So what do you suggest? Regards, Iskren