[Plastic-devs] Fwd: XMLRPC, dead clients, and multiple callbacks

[John T. <jon...@gm...>]

>
> Hi Michael,
> Thanks for this post.  We're currently thrashing out an IVOA- 
> mandated successor to PLASTIC, so your email is particularly timely.
>
>
> On 13 Apr 2007, at 21:25, Michael Halle wrote:
>
>> Hello,
>>
>> I'm experimenting with using PLASTIC with the medical imaging  
>> software
>> we're using to visualize astronomy data.  Since we're doing some
>> retrofitting into an existing app, I've written client code from  
>> scratch
>> to get a feel for the protocol.
>>
>> I've hit a bug that I thought you might have some thoughts about.
>>
>> Here's how I get to the problem:
>>
>> 1. client connects to hub and registers an XMLRPC callback.
>> 2. client listens for messages
>> 3. developer terminates client
>> 4. client doesn't clean up after itself by unregistering
>>
>> 5. develop hacks code and reruns client, repeating 1 and 2.
>> 6. other client sends message to hub
>> 7. first client gets two messages
>> 8. process repeats, and client receives more and more messages
>>
>
> I've seen this problem myself.  Once way to avoid it is to use a  
> different callback each time the client registers, but it's hardly  
> satisfactory.
>
>> The problem arises because there's currently no way to know  
>> immediately
>> that a client has died using XMLRPC:  the callback is  
>> connectionless, so
>> there's no notification of client death for the hub.
>>
>> However, when a client reregisters on the same port it's been run on
>> previously, the hub thinks it's a totally different client.  When a
>> message comes in to the hub, it gets dispatches to these two  
>> "different"
>> clients, which is in fact just one client.  The more "zombie"
>> registrations exist, the more spurious messages get sent to the  
>> single
>> living client.
>>
>> There's no opportunity to clean up the mess, since there really is a
>> client out there listening on the port (ie, the port's not dead).
>>
>> I've thought of a couple ways to fix this problem.  The first is,  
>> "dear
>> developer, please unregister your client like we told you."  Well,
>> clients crash, and experience similar problems, without being able to
>> clean up, so a more robust solution might be helpful.
>
> Agreed.
>
>>
>> A quick way to fix the problem is to say there can be only one client
>> running on one port on a host/interface.  If the XMLRPC URL for two
>> clients are identical, the clients must be identical.  If a client  
>> tries
>> to register itself with an identical callback, it should replace the
>> previous client (this could be controlled by a flag).
>
> I think this is a good stop-gap solution, and unless anyone on the  
> list objects I'll implement it.  I don't think there's anything in  
> the spec that specifically prohibits it.  However, you might have a  
> situation where you do want this behaviour...see below.
>
>
>>
>> In a more elaborate solution, one could also add a "are you this ID?"
>> message, which the hub could send periodically to clean up its  
>> callback
>> list.  The client would return a boolean depending on whether its  
>> client
>> ID matches the one passed to it by the hub.  This solution might be
>> useful, but by itself it doesn't solve the problem completely.
>
> How about this: we change the spec so that the receiving  
> application gets the recipientId, as well as the senderId.  That  
> way it can check if it is the intended recipient, and discard any  
> erroneous messages.  Well-behaved applications could even send the  
> hub a NOT_KNOWN_AT_THIS_ADDRESS message so that the hub can clean  
> up.  Having the client explicitly tell the hub that it _isn't_  
> "FOO" rather than confirming that it _is_ "BAR" removes the problem  
> that the hub might incorrectly unregister an application that's  
> just a bit tardy replying.
> On the other hand, perhaps that's the sort of behaviour that we  
> want: applications have to periodically respond to pings in a  
> timely manner if they want to continue to receive messages.  Anyone  
> else got an opinion on this?
>
> The reason I suggest that you might want an application to register  
> several times at the same address is that you might want to create  
> some kind of gateway application that acted as a proxy for several  
> applications.
>
>>
>> One a partially related note, it seems that no-callback scripts  
>> are the
>>   likely offenders for clients that don't clean up after  
>> themselves and
>> unregister.  Seems like an anonymous client id would be handy in this
>> kind of situation.  Even better, you could have an ID with a set  
>> prefix
>> that could be computed client-side and never and the application  
>> name at
>> the end in a known format.  That way, a script client could make  
>> calls
>> to the hub without registering, but a responding client could  
>> still find
>> out the identity of the caller.
>
> I agree it is pretty cumbersome to do all the registration/ 
> unregistration from a scripting environment when you just want to  
> fire off a quick message.  However, one of the issues we're  
> wrestling with in the new protocol is that we want to improve  
> security a little bit: make it harder for apps that aren't running  
> under the same UID to send messages, and make it harder for apps to  
> spoof one another.  So, if we can come up with a way to make it  
> easier for "anonymous" apps to use the system while being  
> consistent with our security requirements then that would be  
> great.  I'll have a think and get back to you - if you've got any  
> ideas then let us know.  Our current thinking for the new spec is  
> here:
>
> http://www.ivoa.net/twiki/bin/view/IVOA/ 
> ApplicationsMessagingHighLevelProtocol
>
>>
>> Anyway, thanks for any insights you may have on these issues, and  
>> thanks
>> for your code!
>
> Well, thanks for your feedback - as I say, it couldn't be better  
> timed.
>
> John
>