Message-id management revisited

[Mark Taylor]

On Thu, 5 Jun 2008, Alasdair Allan wrote:

>> no - this requires no new state and no processing that you're not already
>> having to do.  The implementation of the new method I'm suggesting would, I
>> think, be:
>>
>> sub getSenderMsgId {
>>   my $self = shift;
>>   my $private_key = shift;
>>   my $hub_msg_id = shift;
>>   my ( $public_id, $msg_id ) = split "_", $hub_msg_id;
>>   $msg_id = "msg-id:" . $msg_id;
>>   return $msg_id;
>> }
>
> Okay, maybe I'm totally misunderstanding what's going on here, but I don't
> see why somebody that wants to make a status call on a process will know the
> hub-msg-id that got sent to the application. The originating application
> sends a message with a sender-msg-id, which gets pushed to the hub, which
> pushes it to the recipient with a new hub-msg-id. When the recipients wants
> to reply( ) it replies to the hub with the hub-msg-id, which forwards it onto
> the originiator with the sender-msg-id in the response. At no time does the
> originiating application know the hub-msg-id. So the only way for the
> originating application to make a status call is to ask the hub to ask the
> recipient about the message sender-msg-id. Which means the hub now has to
> keep state on the mappings between the sender-msg-id and the hub-msg-id,
> because the recipient only knows about the hub-msg-id tag.

I can't follow your logic here.  The sender knows the sender-msg-id 
because it selected it in the first place.  The receiver knows the 
hub-msg-id because it's delivered with the message, and given the
translation method above it can find out the sender-msg-id from that.
So the two ends can agree on a single identifier (the sender-msg-id)
which allows them to work out what message they are talking about.

Are you saying that the above getSenderMsgId() implementation
(which doesn't require any additional hub state) doesn't do what it 
says it does, or are you saying that this functionality is insufficient
to allow sender and recipient to agree on what message they are 
talking about?

> Erm... why do we have seperate sender-msg-id and hub-msg-id anyway? Someone
> remind me? It seems to be adding a whole level of complication, and I can't
> remember what we're getting out of it?

It is desirable for the hub to be the thing that generates the message id,
one reason being that this allows the hub to store state (at least sender,
but possibly other things) in the id and thus avoid having to store
internal per-message state.  If it was the client generating an 
opaque message id and passing it to the hub, then the hub would have to 
store state about who sent it until the response came back.

We were originally going to address this by having the hub generate
the message ID and pass it back to the sender as the return value of
the call() method.  However, Doug Tody didn't like this since it means
that the call() method itself requires a round trip from the sender
to the hub, which would otherwise not be necessary.

By allowing the sender and the hub both to contribute their part of
the message ID as in the current scheme, we get round these problems.
A fringe benefit is that the sender can use the same kind of tricks
to store per-message state in its part of the message ID (though what
state it's going to store there will be entirely application-dependent).

Thinking about the round-trip business however, I think it might be
a bit of a red herring.  If you're using call() as opposed to notify()
you are by definition interested in the response, and so you probably
want to know whether the call() itself is dispatched without error,
which means waiting for a round trip to complete in any case.
I think Doug's concerns might have been motivated by thinking about
firing off a large number of event-type messages using the Notification 
delivery pattern (no response required).  If we agree that, then we
could just have the (hub-)msg-id returned from the call() methods and
dispense with the sender-msg-id altogether.

Alternatively, to confuse matters further, here is another option 
to add to my earlier list, which I think might prove preferable:

   9. hub-msg-id is returned from existing call() methods

      The existing call methods

          void call(string recipient-id, string msg-id, map message)
          void callAll(string msg-id, map message)

      are left exactly the same (except I'm going to change the name of
      of one of the parameters for clarity), except that they now
      return the hub-msg-id:

          string hub-msg-id = call(string recipient-id, string sender-msg-id,
                                   map message)
          string hub-msg-id = callAll(string sender-msg-id, map message)

      Everything will work exactly as at present, except that senders
      which want to know the hub-msg-id (e.g. because they are expecting
      progress messages) will have to wait for the call() method to
      round trip.  Senders which don't care can dispatch the call()
      without waiting around for the return value as at present.


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