SAMPY

Mark Taylor m.b.taylor at bristol.ac.uk
Thu Jul 3 02:24:47 PDT 2008


On Thu, 3 Jul 2008, Luigi Paioro wrote:

> So, what happens if a client performs a call(...) or callAndWait(...) to 
> another client, sending an MType to which the recipient is not subscribed?
>
> I see three possibilities:
>
> 1. The hub returns an empty msg-id;
> 2. The hub throws an error;
> 3. The recipient client returns a response with an error.
>
>
> Presently my Hub doesn't support cases 1. and 2. but hopes in 3. Anyway this 
> doesn't means this is the best solution.
>
> What's your opinion?

I think the answer is 2 above - the client's call() or callAndWait()
should result in an error generated by the hub.

It shouldn't be 1, since clients might ignore the returned msg-id 
(in most cases it's not necessary since the msg-tag can be used instead
to match messages with replies).  In any case that approach wouldn't 
help for callAndWait.

It shouldn't be 3 - in general clients should be able to rely on the 
hub behaving properly even if other clients misbehave in some way; 
this is in line with the general philosophy that wherever possible 
the hub should work harder to make life easier for clients.  To put it 
another way hubs should be coded defensively.  So in this case a hub 
MUST never send a message to a recipient which has not subscribed 
to its MType.  In fact this is written explicitly in section 2.4 of
the spec:

   6. When the hub receives a message for relaying, pass it on to
      appropriate recipients which are subscribed to the message's
      MType. Broadcast messages are sent to all subscribed clients except
      the sender, messages with a specified recipient are sent to that
      recipient if it is subscribed.

A similar question arises with regard to the notify() operation.
It's less important here since the sender probably doesn't care
if the message got there or not, but I'd say that in this case
too an error should result if a notify() is sent to a recipient
which is not subscribed to the message in question.

Do you think this should be clarified in the hub method descriptions
(sec 3.11)?

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