ISSUE: Message-id management

Mark Taylor m.b.taylor at bristol.ac.uk
Thu May 1 08:40:06 PDT 2008


On Wed, 30 Apr 2008, Mike Fitzpatrick wrote:

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

Mike

the scheme as it is stands in the draft can use exactly the trick 
that you describe to avoid storing any per-message state internally.

The most obvious way to do it is for the hub to set its hub-msg-id 
along the following lines:

    <hub-msg-id> = <sender-id>-<sender-msg-id>

then, as you describe, when the response comes back to the hub bearing the 
<hub-msg-id>, the hub can unpack this to work out where and how it's
supposed to forward that response on to the original sender.

I understood that your earlier proposal was to say the sender MUST
supply a msg-id with a format like that above, and the hub MUST leave
it the same when it forwards it to the recipient.

The benefit of allowing the sender-msg-id and hub-msg-id to be different
(though they don't have to be if the hub wants to arrange things
otherwise) is so that the sender and the hub can both decide how they
want to format their part of the ID.  As well as not wanting to 
dictate implementation details where it's not necessary, there may
be practical benefits to this - for instance a particular hub
implementation might want to add a checksum for added security.
If it is obliged by the standard to use a msg-id of a particular form,
and generated by the sender, that would be outlawed.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/



More information about the apps-samp mailing list