Applications Messaging Standard

[John Taylor]

Hi Pat,
Welcome on board.
This does sound pretty good, though as Alasdair has pointed out it  
transfers some of the complexity from the hub to the client.  Our  
philosophy with PLASTIC has always been to make life easy for clients  
even if we make life harder for hubs.  If we are going to require a  
client to be able to do direct socket programming, then I see fewer  
benefits in having multiple wire protocols.  Why not just pick (e.g.)  
XMLRPC and be done with it?  Then you could scan through the ports  
using the XMLRPC library and when you get a connection just call a  
"getUser()" method to decide whether it's the right hub.  As Doug  
says, in most cases you'll get the right port first time anyway.  In  
fact, one could go further an eliminate the hub and go peer to  
peer....each application picks a port in a defined range to host its  
own xmlrpc server.  When an application wants to discover its peers  
it scans this range, and should easily detect whether the port  
belongs to a suitable application.  If the application is going to  
have to scan a list of ports already, I don't see that this is much  
of an extra burden in return for removing the need for a hub.
My only unease about it is my use case of wanting to use the  
messaging system from very simple environments such as IDL.  It is  
almost certainly possible to do so with the file-based bootstrapping  
and a simple enough wire protocol.  It might not be possible (or  
practical) with the socket-based system.

John


On 16 Feb 2007, at 21:14, Doug Tody wrote:

> Thanks Pat, this sounds like a simple and reasonable alternative
> which could provide a fully network-based approach.
>
> One could go one step further and make the "well known port"
> configurable by some means such as an environment variable or command
> line argument (with a fixed built-in default).  The port could
> optionally include a host name.  In actual use on desktop systems
> this scheme could be expected to work the first time 99% of the time.
>
> The scheme is extensible to a simple password security scheme should
> this ever prove necessary.
>
> Regarding wire protocols, a fixed protocol of some sort could probably
> be used to make the initial connection.  Then a simple get keyword
> operation could be used to find out about optional protocols the
> "hub" supports, and any other similar information.  Since this would
> be done on a per-keyword basis, it would avoid having to even parse
> the text file.
>
> As you say, recovery is automatic without having to worry about dreg
> files pointing to dead hubs.
>
> 	- Doug
>
>
> On Fri, 16 Feb 2007, Patrick Dowler wrote:
>
>> On Friday 16 February 2007 04:20, Alasdair Allan wrote:
>>>> My feeling is still that the file-based approach, while inelegant,
>>>> presents fewer problems in practice than the socket-based one, but
>>>> I am prepared to have my opinion changed.
>>>
>>> I don't see any way around using a file to solve this problem, I'd
>>> welcome persuasion, but a file based approach to communicate this  
>>> one
>>> piece of vital information seems to be the only way around it.
>>> Everything else, of course, should go down the wire.
>>
>> Why not have binding/listening to the port be the thing that says  
>> a hub is
>> running. Then clients just have to try to connect to the well  
>> known port (on
>> localhost) to find the hub. Hubs need to try to open that port for  
>> listening
>> to see if a hub is already running; that fails if the port is in use.
>>
>> On a multi-user machine, the initial hand-shake could exchange the  
>> user-name
>> to make sure client and hub are running under the same user  
>> (spoofable, but
>> we aren't trying to make this overly secure, just simple for users).
>>
>> If there is a collision on the port in a multi-user environment, just
>> increment the port number and try again. So clients and hubs start by
>> connecting to port N and checking the user; if they connect and  
>> find the same
>> user is running the hub, the client proceeds and the (2nd) hub  
>> terminates
>> quietly (or not). If the new hub doesn't find anything, it tries  
>> to take the
>> port (starts listening). If the client or hub finds a hub but user  
>> doesn't
>> match, they try again on port N+1. If the client doesn't find a  
>> hub, it
>> probably has to check higher port numbers (in case that users hub  
>> was not the
>> first to start and hence is on port N+something). For sanity and  
>> quick
>> failure, one would want relatively short socket connection  
>> timeouts and to
>> limit the number of times one would increment the port number and  
>> try again.
>>
>> The nice thing about this is that if a hub dies horribly, it isn't  
>> leaving any
>> trail behind that will block the startup of another hub  
>> (the .plastic file).
>> And all you have to agree on is some arbitrary port number, which  
>> is pretty
>> standard in many internet applications.
>>
>> The little user-matching handshake may well not be "independent of  
>> wire
>> protocol" but I really have very little idea of what people  
>> actually mean by
>> that. In the end, both sides of the socket have to be talking the  
>> same wire
>> protocol.
>>
>> In future, this may well extend to the LAN environment simply by  
>> the user
>> knowing which host his hub is on, but there are several magical  
>> ways to do it
>> too (IP multicast, eg), but that's for the future.
>>
>> my 2c,
>>
>>
>