SAMP Bridge

[Mark Taylor]

On Fri, 7 Aug 2009, Luigi Paioro wrote:

> Hi Mark.
> 
> I've given a look at your Bridge tool and IMHO it is not just a toy but a very
> useful component. As you might remember I did an attempt to include the
> inter-host capability in SAMPy. In particular I faced the issue of connecting
> a client to a remote Hub as the Bridge actually does. My idea was to directly
> connect an application to a remote Hub instead of using a bridge, but I must
> say that your approach is very interesting and seducing and I'm seriously
> taking into account the possibility to endorse it within my working context.
> 
> My scenario is quite simple: a server, which is a Beowulf cluster head node,
> where some reduction programs are installed, and remotely connected clients
> launching the reduction tasks. In the head note a Hub is running with well
> defined connection parameters (URL and secret), and a SAMP application
> providing the reduction tasks as a set of private MTypes is locally registered
> with it. Remote clients that want to spawn the reduction processes over the
> cluster, just connect with this remote Hub (knowing the connection parameters)
> and call the tasks through the associated MTypes.
> 
> This approach imposes an additional intelligence to the SAMP client classes,
> which must be able to connect with a remote Hub having the connection
> parameter, but the Bridge approach allows to move this capability just to the
> Bridge application... very nice.

yes, the bridge (maybe multiple bridge instances, one per remote client)
should work as a solution to that.  

I think though that in a situation like this there might 
be a case for introducing some minor changes to the Standard Profile
in a future version, for instance searching for the lockfile location,
or the URL and secret, as the value of an environment variable if
it exists, and otherwise falling back to the ~/.samp file as now.
I've effectively introduced capabilities like that into JSAMP for 
my own use, but since they're not standard, they can't be used as a 
general mechanism.  A small change along these lines should be 
easy for clients to implement, and would introduce quite a bit of
additional flexibility for deployment.  The resulting communications
would be more lightweight than bridging everything.

> I'm writing this mail just before going away for my vacations (thumbs up!), so
> I put down the comments come in my mind just in order to take notes of them
> and maybe start later on a discussion.
> 
> 
> - Point 1
> 
> I'm little concerned about the messages traffic the Bridge introduces (in my
> case performance is worthing). Once a client_1 at host_1 sends a message to
> client_2 at host_2, as far as I understand the steps performed are:
> 
> client_1 -> hub_1 -> proxy_client_2 (bridge) -> hub_2 -> client_2

yes

> I don't know in JSAMP, but in SAMPy each arrow (->) is a message
> serialization/de-serialization step.

and yes.

>                                      It's not such a big problem, but if the
> bridge were included in the Hub as an internal functionality then we would
> have one steps less:
> 
> client_1 -> hub_1 -> hub_2 -> client_2

It would be possible to do it, but I quite like the fact that the
bridge I've implemented uses only the publised SAMP interface 
itself (it's a normal client), so it can work with any hub -
I wasn't sure if this would be possible before trying it.
Having the bridge internal to the hub, while it would make some
efficiency savings, would tie it to a particular hub implementation.

Knocking the number of de/serlializations down from 4 to 3 is 
probably not that much help, but it's true that use of a bridge
does generate quite a lot of traffic, and it may not be suitable
for high-volume situations.

> - Point 2
> 
> In my case the remote server (head node) is really closed to the foreign users
> and I must be sure that unauthorized people cannot connect with it.
> Nonetheless the hub parameters are public since the clients (or the bridge)
> must know them. In SAMPy I faced this problem supporting the HTTPS protocol,
> namely allowing the clients to be authorized thanks to a certificate exchange
> or via Basic Authentication through an SSL channel.

I haven't tried this, but I think JSAMP, and hence the JSAMP hub and 
the bridge, can use HTTPS, either as it stands or with minor changes.
This is (at least should be) true because of the pluggable layer that
JSAMP uses for XML-RPC transport.  I can certainly look into it if 
you or others want, or might want, to be able to do this.

>                                                     The hubs and at least the
> Bridge should support SSL channels. But still this would mean the definition
> of a "Inter-host Profile"...

would it?  It's not clear to me that that is the case.  However, I 
don't know much about SSL.

> In any case, if people are interested in the inter-host communication
> capability and you, Alasdair and me (AFAIK the only three authors of a Hub
> implementation so far) have faced this point at a certain moment, I think that
> a concrete discussion on this issue should start.

yes - between us we're exploring some interesting scenarios.

Enjoy your holiday!

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/