Applications Messaging Standard

[Doug Tody]

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.

 	- Doug