On Thu, 2005-09-15 at 11:53 +0100, Keir Fraser wrote:
> On 15 Sep 2005, at 02:39, Rusty Russell wrote:
>
> > we really do want separate connections
> > for each client: they're logically separate, so overloading them on one
> > transport is going to be a hack.
>
> How does two connections being 'logically separate' imply that it is
> improper for them not to also be 'physically separate'? Multiplexing
> multiple simultaneous connections/transactions onto a single underlying
> page-level transport would seem fine to me!
Um, multiplexing, like any feature, adds complexity: if we don't need
it, don't do it. <shrug>
We have a way of establishing new ringbuffers to talk to the store, we
just currently assume one per domain. Loosening that seems simpler and
more robust than introducing a multiplexing layer, unless you two can
see something I can't?
Christian says:
> My main objections against multiple pages are:
> - setup/teardown overhead: we'll have to add messages to setup
> and teardown a new connection
Which we already have, as above.
> - we have to maintain state about the connection in the daemon
But allowing multiple connections over one transport doesn't change
this.
> - save/restore becomes more complicated
Actually, I think it becomes simpler we simply force the device closed,
which should be handled by libxenstore just the same as a unix domain
socket closing on daemon restart, AFAICT. So it has an appeal.
What was the reason for wanting multiple transactions per connection?
Changing the interface is going to be a PITA, so we should figure out if
we're going to need that soon...
Thanks!
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home