Boxcarring and its implications (was Re: Open-top coordinators andprotocol)

[Alastair Green <alastair.green@choreology.com>]

Hi Mark,

And to this thread ...

Mark Little wrote:

> > Just in case this has been missed in what we have been saying: I am in
> > favour of piggybacking messages where possible. However, I do not believe
> > that we should come up with a protocol that mandates it or requires it
> > because such optimisations may not be possible, or may get in the way of,
> > for example, debugging (one of your examples requiring the disabling of
> > interposition). I would have thought that we could come up with a protocol
> > specification that could address this.

You have to mandate that it is understood on receipt, otherwise it's not
interoperable. In any event, we have to mandate it for *REQ* + CONTEXT, so this
bullet must be bitten.

>
> >
> > For example, in the OTS when using interposition it is entirely legal to
> > delay registration of the subordinate coordinator until the response of
> the
> > actual application message flows back, simply because the context flows
> back
> > on the response as well. If we do not preclude reverse context
> propagation,
> > then such optimisations may actually be more natural.
>
> And as a further follow-on, surely a specification that said something along
> the lines of (and I significantly paraphrase!): "actors send their messages
> to other actors, and if such messages can be piggybacked to save bandwidth
> and improve performance then fine; since this happens at the message level
> it should be transparent to the actors." Then if you want to use
> interceptors at either end of a protocol-pipe sobeit, and if you don't
> that's fine too; importantly we don't say how this happens, leaving it up to
> vendors. The actors who sit on top of these pipes don't see the intelligence
> that they possess (assuming they do multiplexing/demultiplexing), and the
> protocol remains easy to understand. The drawback is in terms of
> interoperability, where sender and receiver must have the same intelligence
> (does not have to be implemented in the same way though)

This will inevitably have protocol implications, at the messaging level (format of
compound messages, BTP aware endpoints, addressing). The problem cannot be avoided,
even if you rest with implicit context propagation. We are sending > 1 message to >
1 endpoint, through 1 ostensible endpoint, and the ostensible endpoint must have
special intelligence. You can compose a compound message however you like, but the
sender/receiver cannot be unaware of its compoundness. This implies that the
receiving interceptor becomes an actor in our scheme, maybe as simple as a special
computable address (any known BTP address with the suffix set to a special value of
BOXCAR?), plus an agreement to allow n protocol messages in n headers, or perhaps
to introduce some BOXCAR message.

Alastair
begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard