Re: [vwrap] thinking about LLIDL and the future

[Morgaine <[e-mail]>]

Righto Meadhbh, I'm looking forward to that.

It's worth noting that this design pattern works for many services and
subsystems in our kind of VW architecture.  Wherever a capability enables a
service that operates over a separate transport, the capability grant can
supply dynamic IP:port pairs for the transport and hence quite trivially
harness load balancing for the service in question.

We can certainly apply this not only to object updates but also to group IM,
world notifications, and to search.  Any region-specific assets such as
terrain also fit the model well for load-balanced streaming, and even baked
avatars served from load-balanced pools fit the model.

It's a generic design that is much more flexible and controllable than
access dispersal to dynamic pools through DNS or through load balancers, and
it provides good security as well, and no single point of failure.


Morgaine.




================================

On Sat, Jul 17, 2010 at 7:27 AM, Meadhbh Hamrick <[e-mail]>wrote;wrote:

> okay. i think i understand you and dzonatas well enough to go out and
> write another, completely unofficial, possibly experimental draft for
> the group. then maybe a little bit of PHP and JavaScript to
> demonstrate a few of the features.
>
> again, thanks for the comments (and this is by no means the end of the
> commentary on my extended type system.) i think it's just easier for
> me to have a conversation about it after having real documents and a
> sample implementation to look at.
>
> i'm going to probably drop out of the conversation for a week as i go
> off and work on this stuff. i'll keep a lookout for additional
> comments, and try to address them in my next draft. but i probably
> won't have bandwidth to discuss them for a week or so.
>
> -cheers
> -meadhbh
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>
>
>
> On Fri, Jul 16, 2010 at 10:41 PM, Morgaine
> <[e-mail]> wrote:
> > That's correct, I was describing flows at the capability level, not at
> the
> > transport level.  The transport is exactly as you deduced, namely with
> > separate transports for capability request-response and for asynchronous
> > event messaging.
> >
> > When you send an ENABLE to the capability that controls a particular
> > asynchronous event stream, you receive back the normal capability OK
> > response on the same channel as the request (as expected), but the event
> > messaging that this enables occurs on a distinct channel at the transport
> > level.
> >
> > This makes a lot of sense for practical implementations, because event
> > messaging requires high bandwidth and low latency and so it is best
> handled
> > on a separate transport and using the most efficient form of
> serialization.
> >
> > As an implementation example, the OK response from the request to the
> > capability could return the IP address and port of the event messaging
> > source host, the client would open a TCP stream to it, the source host
> would
> > send events asynchronously down the pipe, and the client's event listener
> > would dispatch the event frames to appropriate event handlers as the
> > messages arrive.
> >
> > Different event-generating capabilities could choose to return different
> > IP:port pairs to harness dynamic load-balanced server pools and to
> provide
> > parallel pathing, or they could choose to share a common event transport
> ---
> > these would be simple site configuration choices.
> >
> > Note that this is highly scalable, since it allows any number of servers
> to
> > participate in event generation and distribution.  No longer do updates
> have
> > to come from a single, horribly overloaded and totally non-scalable
> > simulator host.
> >
> > Consistent with David's regular exhortations, nothing in the above
> precludes
> > this model from working in the legacy deployment architectures of SL and
> > Opensim:  single simulator operation is still supported by the design,
> but
> > it offers additional capability for more scalable deployments.
> >
> >
> > Morgaine.
> >
> >
> >
> >
> >
> > =====================================
> >
> > On Fri, Jul 16, 2010 at 7:45 PM, Meadhbh Hamrick <[e-mail]>
> > wrote:
> >>
> >> Interesting. I had been thinking that the message semantics would
> require
> >> a response on the same channel as the request. What you're talking about
> >> seems to be a little higher level than what I'm pitching. (Thx for
> pointing
> >> out I wasn't clear about this)
> >>
> >> So.. the way I'm modeling it is that you have message interactions that
> >> are tied to the same transport session. So if you ask for something with
> >> http(s), you get it back via http(s) on the same connection.
> >>
> >> But it's definitely true that an application layer entity can coordinate
> >> messages, only I think we should make a "virtual" connection that spans
> >> actual connections.
> >>
> >> But I still think it's advantageous to think of interaction patterns in
> >> terms of message flows over specific connections, otherwise we have to
> start
> >> adding application layer transaction id's to correlate responses to
> >> requests. Also, since trust seems to be associated with connections (by
> way
> >> of (D)TLS), it's probably a good idea to not cross trust boundaries in
> >> interactions across connections, otherwise we would have to model that
> in
> >> the application layer as well.
> >>
> >> At the end of the day, we have message patterns that look like:
> >>
> >> * send, no reply expected
> >> * request, response expected
> >> and
> >> * unsolicited message.
> >>
> >> The first two can be modeled with request/response, but the last one has
> >> unique characteristics that must be modeled.
> >>
> >> -cheers
> >> -meadhbh
> >>
> >> On Jul 16, 2010 11:05 AM, "Morgaine" <[e-mail]>
> >> wrote:
> >>
> >> Considering asynchronous messages to be emitted in response to a CRUD
> >> operation on an appropriate resource fits in perfectly with the notion
> of
> >> Capabilities though.  They ARE solicited, by a request to a resource.
> >>
> >> As in my earlier example of the text-only client, the CRUD operation
> >> UPDATE(scenegraph_updates_capability, ENABLE) was not invoked by the
> client
> >> (or it was invoked with the argument DISABLE), and hence that resource
> saves
> >> time and bandwidth by not sending the unwanted scenegraph updates.  If
> >> instead the resource were set to ENABLE, those update messages would
> >> certainly be appearing in response to the ENABLE request, so it's a
> natural
> >> interpretation.  And of course it's very helpful to have such events
> >> controlled by a capability.
> >>
> >> The alternative model in which events are considered normal CRUD
> >> operations on an event queue in the reverse direction is actually
> incorrect,
> >> because then those operations would require responses themselves, and
> that's
> >> not what we want.  Events don't fit the synchronous request-response
> model,
> >> because they're not synchronous, and are ill-suited to a 2-way
> >> request-response paradigm for every event message.
> >>
> >> That's why I prefer the unidirectional model in which events occur as a
> >> sequence of zero or more messages in response to a normal CRUD
> operation.
> >> It's a clean model because the responses travel in the reverse direction
> >> perfectly naturally (since they're responses) and do not themselves
> require
> >> further ACKs.  It's also justified because, after all, we will require a
> >> means of enabling / disabling updates and other asynchronous event
> >> notifications.  This model kills two birds with one stone, and it's a
> >> natural fit for capabilities.
> >>
> >>
> >> Morgaine.
> >>
> >>
> >>
> >>
> >> ==================================
> >>
> >> On Fri, Jul 16, 2010 at 5:09 PM, Meadhbh Hamrick <[e-mail]>
> >> wrote:
> >> >
> >> > > EVENT is not a...
> >>
> >> _______________________________________________
> >> vwrap mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/vwrap
> >>
> >
> >
> > _______________________________________________
> > vwrap mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/vwrap
> >
> >
>