SAMP Bridge

[Luigi Paioro]

Mark,

> 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.

   this options sounds good. It recalls the system used by the DBus
people. I would add the possibility to specify a non-standard lockfile.
So, for example, the environment variable might be something like (in
pseudo EBNF):

name     ::= 'SAMP_HUB' ;
value    ::= std | ? any other profile dependent string ? ;
std      ::= 'std:', endpoint ;
endpoint ::= lockfile | params ;
lockfile ::= "lockfile=", ? any valid file path ? ;
params   ::= secret, ",", url ;
secret   ::= "secret=", ? any string ? ;
url      ::= "url=", ? any valid URL ? ;


Examples:

SAMP_HUB = \
"std:secret=75fb6691223bb6e6,url=http://127.0.0.1:42866/xmlrpc"

or

SAMP_HUB = \
"std:lockfile=/home/luigi/.samp-1/samp-hub-12019-1"


the "std:" prefix specifies that the endpoint refers to a Standard
Profile hub... I think that in principle the environment mechanism can
be used even with other profiles, thus a prefix which specifies the
profile type might be useful... but this is just an idea.


> 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 agree.


>>                                      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.


I was rather thinking to both possibilities: the bridge as a stand alone
application launched as a separate process (as it is now) and as a
client internally handled by the hub process, jumping the
serialization/deserialization steps... something like:

client_1 -> hub_1      proxy_client_2 (bridge) -> hub_2 -> client_2
               |               ^
               |   internal    |
               +---------------+

this should slightly improve the performance, but certainly it means
that, in order to have a better performance, one is tied to a certain
implementation. In any case I'm not sure it is really worth doing it.


> 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.

Thanks

> 
>>                                                     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.

if everything remains at pure SSL or TLS level with X.509 certificates 
then probably nothing is needed to be defined at profile level.

However my experience is that normal end-users (client side) are not 
really happy dealing with X.509 certificates while the usual 
user/password system is preferred and more familiar. In that case SRP 
for TLS Authentication could help and maybe it wouldn't require other 
specifications at profile level as well.

At the beginning of SAMPy development I investigated the Secure Remote 
Password protocol trying to adopt it, but alas the standard ssl Python 
module is based on OpenSSL which has introduced the SRP support only 
recently and thus Python is not yet able to deal with it.

There is, though, a third possibility, which is the one adopted by me 
with SAMPy, that is the usage of Basic Authentication over an SSL/TLS 
channel (HTTPS) with the certificate provided only at server (hub) side. 
This is a rather secure authentication system: the SSL channel is opened 
once the client accepts the server certificate and then the client is 
authenticated/authorized through the usual Basic Authentication system. 
The user and password are stored in a storage system server side, that 
in SAMPy is a Berkeley Database with a well defined storage format (a la 
Apache).

Even in the last case described above probably nothing special is needed 
to be specified at profile level unless it is not thought to standardize 
the password/authentication file format in order to be usable by 
different hub implementations (in this case maybe even the SRP verifier 
file should be considered, but this is not clear to me).



Cheers,

   Luigi