JSAMP HUB waits for callee before returning to caller

[Hugo Buddelmeijer]

Hi Mark et al.,

The SAMP HUB in JSAMP (and thus TOPCAT) causes unnecessary delays with 
clients that do not immediately return the XML-RPC call from the HUB.

The astropy HUB does not show this behaviour, so the delays can in 
principle be avoided. Perhaps the JSAMP HUB can be improved to mimic the 
astropy behaviour?


** Explanation and Solution **

Before returning the XML-RPC call of a calling client, the SAMP HUB in 
JSAMP first waits for the called-upon client to return their XML-RPC call.

Instead, for 'call' and 'callAll', the HUB could return the XML-RPC call 
of the caller directly, before initiating the XML-RPC call to the 
callee. For 'callAndWait', the HUB could return the XML-RPC call from 
the caller as soon as it has a SAMP 'reply' from the callee, 
irrespective of whether the callee has returned their XML-RPC call.


** Demonstration **

The attached two files demonstrate the problem. client1.py contains a 
client that causes problems. client2.py contains a client that sends 
messages to client1 through callAndWait, call, and callAll. The essence 
of client1 is this:

    def receive_call(...): # Receive a SAMP call.
        client.reply(...)  # Immediately return a SAMP reply.
        time.sleep(5)      # Perform desired time-consuming action.
        return             # Return an XML-RPC reply.


With the astropy HUB, all the calls from client2 take about 0.02 
seconds. With the JSAMP HUB, the calls take 5.02 seconds. The SAMP reply 
arrives even before the 'call' and 'callAll' XML-RPC function returns. 
Furthermore, a 'callAndWait' with a timeout of 2 seconds will also take 
5 seconds.

It would be great if JSAMP could become even more robust than it already 
is. It is currently even possible to perform a denial-of-service attack 
on TOPCAT using SAMP!


** Workarounds **

Two workarounds for this problem are:

1) Have all clients terminate their incoming XML-RPC call immediately 
before performing the actions associated with the incoming message. 
Although this is probably the best behaviour, it seems to require quite 
some complexity for clients, like multi-threading and such. Perhaps so 
much complexity that the 'S' in SAMP is not applicable anymore. Anyone a 
suggestion on how to rewrite client1.py in such a way as cleanly as 
possible?

2) Add a try/except loop around every SAMP call with its own timeout in 
each client. This might be necessary anyway, since even if JSAMP is 
updated it might take a while before all users use the new version. 
However, this makes 'callAndWait' superfluous and also requires 
something like multithreading.


Thanks for your insight,

Hugo




-------------- next part --------------
A non-text attachment was scrubbed...
Name: client1.py
Type: text/x-python
Size: 399 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/apps-samp/attachments/20140623/409a81dd/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client2.py
Type: text/x-python
Size: 2282 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/apps-samp/attachments/20140623/409a81dd/attachment-0001.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3257 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.ivoa.net/pipermail/apps-samp/attachments/20140623/409a81dd/attachment.bin>