[Plastic-devs] Fwd: XMLRPC, dead clients, and multiple callbacks
Brought to you by:
johndavidtaylor,
thomasboch
|
From: John T. <jon...@gm...> - 2007-04-15 11:19:54
|
> > 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 > |