SAMP Bridge

[Luigi Paioro]

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.

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

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

However this would require the definition of a SAMP "Distributed 
Profile" or "Inter-host Profile"...


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


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.


Cheers,

   Luigi



Mark Taylor ha scritto:
> As mentioned in my previous message, JSAMP 1.0 contains a new component
> called the Bridge.  It is documented at the following URLs on the JSAMP
> site:
> 
>    http://software.astrogrid.org/doc/p/jsamp/1.0/bridge.html
>    http://software.astrogrid.org/doc/p/jsamp/1.0/commands.html#Bridge
> 
> as well as in the javadocs.
> 
> What this allows you to do is to connect two (or more) hubs together,
> so that clients on one can talk to clients on the other, as if they
> were all registered on the same local hub.  The bridge is a normal
> SAMP client (or rather a number of SAMP clients - it will register
> multiple times with each connected hub), so it can work with any
> hub implementations, not just JSAMP's.
> 
> This development was largely inspired by Ivan and Igor's entertaining
> demonstration at the Strasbourg Interop which some of you might 
> remember, though the idea of inter-host messaging has been lurking
> in the background since the early days of PLASTIC.
> Use of the bridge would make the kind of collaborative working in
> that demo (clients running on different machines communicating with 
> each other) somewhat easier to set up, and would solve some, though 
> not all, of the issues that the simple approach (use one hub and 
> point all clients at it) encounters.  It does not solve the problem
> of firewalls getting in the way, though it could be a step towards
> doing that.
> 
> An obvious use of the bridge would be connecting two hubs on two 
> different hosts, used by two different people, so they can share
> data and control of applications.  Another possibility would be 
> connecting client communities which use incompatible SAMP Profiles.
> You may be able to think of other similar or maybe quite different 
> uses.  
> 
> I'm not sure yet whether this is a useful infrastructure component
> or just a toy.  I'm interested in other people's opinions on the topic.  
> Any further discussion, either privately or on list, is very welcome.
> 
> 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/