Message-id management revisited

On Tue, 3 Jun 2008, Mike Fitzpatrick wrote:

>  app.status.progress           msgid,str       progress string
>  app.status.progress.percent   msgid,float     percentage completed (float)
>  app.status.progress.timeLeft  msgid,int       est. time remaining (sec)

oof. These get us back into deep water.

Progress messages are a good idea, but...

As the messaging is currently set up, the recipient does not use the same msgid as the sender does to identify a given message - the sender has the sender-msg-id and the recipient has the hub-msg-id and they are probably not the same, as described in the Asynchronous Call/Response part of the "Sending and Receiving Messages" section. So these progress messages won't work (the recipient won't know which message the sender is referring to) unless there is some mediation by the hub to match the recipient's msgid with the sender's one. The same applies to any other MType which needs to refer to a previous message (an abort MType springs to mind as another possibility).

Yes this is a consequence of the scheme in which hubs and senders get to choose their own msg-ids which I argued for and Mike was, at least initially, against - see the ISSUE: Message-id management thread.

I can think of a lot of different ways this could be addressed, with associated disadvantages. Amongst other possibilities:

1. sender generates single free-form msg-id
   • means that hub does not have control over ID form, so can't use it to avoid having to maintain state internally
2. sender generates single msg-id with fixed form <client-id>-<msg-tag> (this was Mike's original proposal)
   • hub can avoid maintaining *essential* state, but if it wants to keep track of other per-message info (e.g. timestamp, checksum, ...) it will need to store it internally. Also need to worry about what happens if the sender does not follow the requirement for how the id is generated - better to have an interface in which it's impossible to do the wrong thing.
3. hub generates single free-form msg-id (this is like what happened in PLASTIC, but Doug raised the issue of eliminating unnecessary round trips)
   • has to return it to sender from call() method, meaning that message call (though not message notify) requires a round trip. Also means that sender does not have control over ID form, so sender can't use it to avoid maintaining state internally (less serious problem than for hub).
4. hub provides hub-msg-id -> sender-msg-id translation method
   • OK but slightly messy
5. receiveCall() method passes sender-msg-id as well as hub-msg-id
   • OK but slightly messy. Doesn't sound so bad if you rename sender/hub-msg-id as sender/hub-msg-tag or something.
6. send progress info as a variant of hub call reply() instead of via MType
   • confusing - better if reply() just does one thing
7. send progress info via a new hub call progress() similar to reply() instead of via MType
   • messy and less extensible - might want to do something other than progress involving msg-ids.
8. do nothing
   • can't transmit progress information

I think I'd favour, in order: 5, 3, 4. Anyone else?

Mark

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