On Fri, 16 Feb 2007, Mike Fitzpatrick wrote:
> Admittedly it will be a rare case, but I think I see a hole in this
> scheme: Assume two users start msg-enabled apps at about the same
> time, so the first users get the well-know port (say 2000) and the
> second user gets (N+1, 2001). If the first user shuts down then port
> 2000 is now free, if the second user then starts another msg-enabled
> app in their session it will try to connect to port 2000 and/or
> possibly start a second hub since the port is free and it has no
> reason to look for N+1.
If what the protocol does is allow a client to contact port N and say, do you have a connection for user X, then the query will return port N+1 if that is where the existing connection is active. So I think it still works.
> How about a scheme where the address is some agreed base value (call
> it 2000) but apps/hubs use the userid as an offset? This guarantees
> a unique port for each user, can be overridden by an env var to start
> a separate session, and avoids "port scanning" since a user will only
> every try a single port number. I dont know if Windows has a concept
> of 'userid' but they could just fallback to the base address anyway.
> Assuming the userid is the same across a LAN all we need is a host
> name to connect to "our" hub on a remote machine since we'll already
> know what the port will be.
You could do something like that, but it starts to get to be a kludge. Since only one or at most several ports are likely to actually be used, it seems better to have a scheme that only uses a small range of ports.