handling unknown messages (pt 2 of TODO)

[Iskren Chernev]

2011/4/11 Kristian Høgsberg <krh at bitplanet.net>

> On Sun, Apr 10, 2011 at 1:47 PM, Iskren Chernev
> <iskren.chernev at gmail.com> wrote:
> > 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?
>
> Yeah, that's the straight forward idea.  I was thinking that we could
> be a little smarter about the encoding and use the 16 bits we
> currently use for siz a little differently.  Make the upper bit of the
> size field reserved, the next three the number of fds and the
> remaining 12 bits the size of the message.  That means we're reducing
> the maximum message size from 64k to 4k bytes, but that's ok, the
> Wayland protocol isn't intended for bulk transfer (send a pipe fd for
> that).  The reserved bit must be zero and I'm thinking we can use it
> to indicate the presence of optinal header fields.
>
> Ok, that makes sense.


> > 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".
>
> The per-client id space has a couple of benefits.  It greatly
> simplifies the id allocation (since now the client is in charge of the
> entire 32 bit id space) and it means that there's no way a client can
> possible address other clients objects.  The subscription step is when
> the client assigns a client id to a global object.  With this step in
> place, we could even change the type of ids used for global objects to
> be something else - strings, for example.  Anyway, this is something
> I've been working on, I've just been distracted enough to not actually
> finish it for the previous one or two months...
>
> > 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?
>
> Yup, that's another benefit to the subscription step.  The client can
> specify which version of the interface it understands.  The idea is
> that interface should always be backwards compatible, clients are
> expected to ignore messages introduced in newer versions.
>
> So basically, even if you implement the subscription mechanism the number
of file descriptors should be given -- except in the case where the server
knows all previous versions and sends only the messages the client knows of.
Maybe all messages should have the version number they were introduced in.


> Kristian
>


So I can safely implement the passing of the number of fds the way that you
describe it (safely -- I mean it wont be redundant after a few months :)).

Regards,
Iskren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110411/811eebee/attachment.htm>