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.
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,
>
>
Received on 2007-02-16Z22:14:45