Re: [vwrap] thinking about LLIDL and the future

[Morgaine <[e-mail]>]

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;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
>
>