Applications Messaging Standard

[Doug Tody]

Also, a clever implementation could support multiple user contexts and
allow a user client/hub to connect on the first attempt, even if there
were multiple active user sessions.


On Fri, 16 Feb 2007, 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,
>> 
>> 
>