Applications Messaging Standard
dtody at nrao.edu
Fri Feb 16 13:42:23 PST 2007
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
>> localhost) to find the hub. Hubs need to try to open that port for
>> 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
>> 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
>> 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
>> 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
>> 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
>> The nice thing about this is that if a hub dies horribly, it isn't leaving
>> trail behind that will block the startup of another hub (the .plastic
>> 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
>> that. In the end, both sides of the socket have to be talking the same wire
>> 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
>> too (IP multicast, eg), but that's for the future.
>> my 2c,
More information about the apps