ISSUE: Message-id management

[Mike Fitzpatrick]

On Wed, Apr 30, 2008 at 3:54 AM, Mark Taylor <m.b.taylor at bristol.ac.uk>
wrote:

> The Asynchronous Call/Response pattern described in section 3.9 has the
> sender generating an ID which is used to match the message with its response
> between sender and hub, after which the hub generates a different ID which
> is used to match the message with its resopnse between hub and recipient.
> This permits use of any value for message ID by the sender.
>
> Some feel this is unnecessarily complicated and prefer a required
> message-id of form <senderId>-<uniqueKey> which would
> enable the same string to be used for all stages of the message's life.
>

To be clear, the issue of complexity and the form of the msg-id were
separate ideas,
not that the latter was proposed (entirely) as a solution to the former.

On the issue of complexity:  The doc Sec  3.8 makes a point of
distinguishing between
the sender-msg-id and hub-msg-id and to its credit does not forbid them from
being
the same.  OTOH, it doesn't say whether the hub-msg-id sent to multiple
recipients
needs to be the same or if this is a per-recipient unique value.
    Where things get complex is that the Hub needs to maintain a mapping
between
the hub-msg-id and the original sender-msg-id (as well as the sender-id if
the string is
truly random) so it can return a response with the original sender-msg-id.
Presumably
you would also want to keep track of a recipient-count so that once all the
replies are
received you can clean up, however we don't impose any requirements on when
this
is checked so we have no real way of enforcing the requirement that every
Request
have a reply and could end up with a lot of this mapping/state structure
building up in
the hub.
    If a mapping of ids and senders is to be maintained anyway, what extra
benefit  is
there to having different ids between the sender-hub and hub-recipient over
keeping a
single id throughout the message cycle?

On the form of the msg-id:  The suggestion was made that including the
sender-id as
part of the msg-id could avoid maintaining the mapping in the hub entirely
since the
sender-id could always be derived from the msg-id, and when a client replied
the
hub would simply pull the sender-id out and deliver the response.  The only
hub structure
that would need to be kept would be a reference count for the message-id so
you would
know how many clients (or perhaps also who) didn't reply.

So, the model is that outgoing Messages are routed by the client-id/mtype in
the method
signature (since there can be either a single known recipient or some
unknown number
recipients), and replies are routed using the msg-id as a form of return
address (since there
will only ever be one sender-id no matter how many replies are sent based on
that msg-id).

Cheers,
-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/pipermail/apps-samp/attachments/20080430/a4fa32a0/attachment-0001.html>