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,
-- Patrick Dowler Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.)Received on 2007-02-16Z21:01:43