(Sorry for replying late to this thread)
On (Tue) May 25 2010 [09:26:43], Darryl L. Pierce wrote:
On Tue, May 25, 2010 at 09:27:05AM +0200, Andrew Beekhof wrote:
> > I was thinking of having some more fields: feature bits negotiated
> > between the host and guest libraries (header sizes may vary, for
> > example), once all features are negotiated.
>
> I think we need to include this in the header of every message sent between the
guest and host.
Did you mean to say "we don't need"?
> I'd imagine that the capabilities would be part of the body of messages
exchanged during the negotiation stage.
> After that they're not going to change, so why resend every time?
+1 Negotiate the features once. But how often would those features change?
Depending on how long the communications go on between the two sides, would
they at some point need to re-negotiate the feature set? Maybe the host
could include a hash id for the feature set and, if things change, they
would sync-up again. Thoughts?
I too meant doing it once on start-up.
How often to do this: on the host:
- when we receive a guest_closed notification and on the next
guest_opened notification
On the guest:
- Similar, when POLLOUT goes off and comes back on, indicating the host
side of the connection dropped and came back on.
> > if (host_features < 0) {
> > ...
> > } else {
> > features = guest_features & host_features;
> > }
> >
> > if (features & F_CLIPBOARD2) {
> > ...
> > }
> >
> > something like that.
> >
> > Anyway, these are just some quick initial thoughts; let me know if
> > there's any more discussion surrounding the use-cases and we can decide
> > on the design.
> >
> > Also, Perry mentions an XML payload, but the payload could really be
> > anything; example a clipboard copy-paste app will just have free-flowing
> > data (unless a key-value protocol is being proposed as part of the
> > libvirtioserial library).
>
> Agreed, the type in the header should void* rather than char* and we should include
a "type" field in the header.
This sounds logical to me. And to ensure things are in sync on both
ends, we should have some kind of starter that indicates the beginning
of an envelope.
So the envelope could look like:
0x00 0x0d 0x01 0x14 0x01 0x01 ; start of envelope
0x00 0x00 ; payload type
0x00 0x00 0x00 0x00 ; payload size
0x00 0x00 0x00 0x00 ; payload checksum
... ; payload
0x01 0x01 0x14 0x01 0x0d 0x00 ; end of envelope
Thoughts?
This could be unnecesary if we have strict checking for connection
re-establishments on both sides of the connection (as mentoined above).
In that case, we just need to send the message size each time and we can
be sure our connection is in sync.
If, however, we do find ourselves getting out of sync, we could send a
stream of magic bytes (say 12K bytes, each with the magic words
0xdeadbeef), which either end recognises and causes a connection reset.
Amit