Date: Thu, 29 Mar 90 06:43:53 PST
Sender: Mike Spreitzer:PARC:Xerox
Subject: Do we need a world registry?
To: PCedarImplementors^:PARC:Xerox
Cc: Mike Spreitzer:PARC:Xerox

If you run multiple PCedar worlds on a UNIX machine, and want to debug one of them remotely, you need a way to identify which world you want. (Howard has a workable but clunky solution in place now.)

If you run multiple PCedar worlds on a UNIX machine, and want to connect to one of them from a remote terminal (we can't do this yet, but...), you need a way to identify which world you want.

If you run multiple PCedar worlds on a UNIX machine, and want to use one of them as a remote terminal for some host Cedar world (we can't do this yet, but...), you need a way to tell that host which world is to provide terminal services.

If you run multiple PCedar worlds on a UNIX machine, and want to connect to one of them with telnet (we can't do this yet, but...), you need a way to determine the port number to use.

If you run multiple PCedar worlds on a UNIX machine, and want to Bridge to one of them (we can't do this yet, but...), you need a way to distinguish among them.

The list probably goes on. I think all these examples reduce to the problem of assigning port numbers. One of the reasons we can't do most of those things yet is that I don't know of a good, in-place solution to this problem. I know of two poor in-place solutions, and one that requires some work (and new administrative overhead).

Poor solution 1: The user tells both sides (eg, `host' and `terminal') which port number to use, for each application. This is bad because it puts a lot of stupid burden on users, especially as the number of applications that need this information grows. Not only do users have to remember a lot of random numbers, but they have to choose them correctly according to the allocation guidelines (whatever and wherever they might be). Note that this is the soution that Cirio now uses: there's a default port number it uses, and if there are more than one Cirio-nubbed Cedar worlds on a machine, the user needs to ensure that they're using different port numbers (by manually choosing and specifying non-default port numbers for all but at most one of those worlds) - and the user has to give the port number to use to the CirioRemote command if a world other than the one using the default port is to be debugged.

Poor solution 1-A: To eliminate the increase of complexity with number of applications, and reduce the randomness of the numbers users manipulate, introduce the concept of `world number'. A world number is a very small integer: usually 0, and almost always less than 5. Each application chooses the port number to use from amongst those allocated to it, taking the world number as a parameter. For example, Cirio might choose port number 4815 + worldNumber. For another example, a remote host needs three port numbers from the terminal, and could choose 3*worldNumber+base, 3*worldNumber+base+1, and 3*worldNumber+base+2. The user tells each world what world number it is to use (or lets it default to 0); the user also tells the `remote' side of each application the world number of the desired world on the `host' machine. The user is responsible for assigning *distinct* world numbers to concurrent worlds on a machine, and remembering the world number and providing it to the remote side of each application. Now that we have only one number characterizing a whole world, it becomes reasonable to put a label in the upper-right corner of the screen showing that number. It would probably be worthwhile to put a small package very low in the food chain to export this number through a Cedar interface. By putting in every world another new package that responds to a certain standardized new kind of query, it becomes possible to get a listing of all the cedar worlds running on a machine. These last ideas would help the user in assigning and remembering the world numbers.

Poor solution 2: The `host' side of each application chooses the port number, and tells it to the user, who must remember it and tell it to the `remote' side of that application. I think the obvious way for an application to choose a port number is to (indirectly through a decent Cedar interface) use UNIXs ability to allocate new, distinct port numbers. This means the port numbers will be long and random, and thus easily forgotten by users. But the user *is* relieved of the burned of allocating the port numbers.

Good, not in place, solution: Use world numbers as above, except that world numbers are assigned not by users but by a new UNIX service. For example, we could configure our machines so that amongst the programs started at every UNIX boot is a new program that communicates by UNIX interprocess communication methods (whatever they are) and keeps track of what world numbers are currently in use so as to be able to allocate small ones. We could probably arrange that `normal' termination of a Cedar world includes notifying this `world number daemon', and provide a way for users to forcibly free world numbers allocated to abnormally terminated Cedar worlds. Using a keep-alive protocol would be a bad alternative because Cirio-frozen worlds would stop replying (or could we put something low enough that this wouldn't be a problem?; perhaps it should be PCR, rather than Cedar, that is responsible?). I am somewhat dis-enthused about adding to the list of things you must do to your UNIX machine in order to be able to run Cedar. However, we could arrange that absence of the world number daemon does not prevent you from running Cedar, but only shifts the world number allocation burden onto the user (who probably won't need to know about it at first because he probably won't need to distinguish among multiple Cedar worlds on one machine).

Thoughts?

Mike

Date: Thu, 29 Mar 90 09:26:01 PST
In-reply-to: "Mike Spreitzer:PARC:Xerox's message of Thu, 29 Mar 90 06:43:53 PST"
Sender: Howard E Sturgis:PARC:Xerox
Subject: Re: Do we need a world registry?
To: Mike Spreitzer:PARC:Xerox
Cc: PCedarImplementors^:PARC:Xerox
Reply-To: Howard E Sturgis:PARC:Xerox


For the record, two issues led to the present (non) design for Cirio ports.

1) Alan Demers would like to see some sort of authentication required before a CirioDebugger can connect to a Debuggee. Because he does not have a proposed design, and has no time to produce one, we chose an adhoc (non protected) scheme for the interim.

2) If a Cedar world uses a port and subsequently goes away in some unpleasant manner, then that port remains unusable for some (unknown) period of time. (This is a Unix feature.) Thus, the use of precomputed port numbers (such as from a reused world number) can lead to an unusable port.

Howard

Date: Thu, 29 Mar 90 10:45:58 PST
In-reply-to: "Your message of Thu, 29 Mar 90 09:26:01 PST"
Sender: Mike Spreitzer:PARC:Xerox
Subject: Re: Do we need a world registry?
To: Howard E Sturgis:PARC:Xerox
Cc: Mike Spreitzer:PARC:Xerox, PCedarImplementors^:PARC:Xerox

1) Even in a scheme with authentication, there will be a need to identify which of possibly several worlds on a machine is to be debugged.

2) I don't understand your use of the word `pre-computed'. In methods 1 and 1-A, the numbers are assigned by users; in method 2, UNIX does the allocation, and presumably won't hand out an unusable port number; and in the good solution, the world number daemon supplies numbers on demand, based on the current state (which can remember how long ago a number was released). In all but solution 2, we need to get UNIX to reveal a useful upper bound on how long a port number remains unusable; is that simply a constant we need to discover? is there a way to test whether a port number is currently unusable?

Date: Thu, 29 Mar 90 13:47:47 PST
In-reply-to: "Mike Spreitzer:PARC:Xerox's message of Thu, 29 Mar 90 10:45:58 PST"
Sender: Howard E Sturgis:PARC:Xerox
Subject: Re: Do we need a world registry?
To: Mike Spreitzer:PARC:Xerox
Cc: Howard E Sturgis:PARC:Xerox, PCedarImplementors^:PARC:Xerox
Reply-To: Howard E Sturgis:PARC:Xerox


I did not send my message as a criticism of particular mechanisms, only to explain the social and technical reasons why Cirio does not have a reasonable one. As for your responses:

1) I agree fully.

2) Alan could tell us what the timeouts are, I don't know. However, see also my remark below.


Remark:

There is a general mechanism that has been used in the past for getting an agreement on port numbers for communication. If A wants to talk to B, A calls on B's machine using a wellknown port number, and requests a port number for the conversation. B's machine responds with a usable conversation port number, following this the interaction on the wellknown port is terminated. Further communication takes place on the conversation port. Why don't we use such a mechanism?

Date: 29 Mar 90 13:45:29 PST
In-reply-to: "Mike Spreitzer:PARC:Xerox's message of Thu, 29 Mar 90 06:43:53 PST"
Sender: Michael Plass:PARC:Xerox
Subject: Re: Do we need a world registry?
To: Mike Spreitzer:PARC:Xerox
Cc: PCedarImplementors^:PARC:Xerox

It ought to be not too hard to use system-5 shared memory as a means for
assigning short identifiers. Just map in a shared segment with a
well-known name (id? key? i've forgotten the terminology, but it's a
32-bit number that you get to make up), and test-and-set through it to
find an unused slot. There should also be enough space associated with
each slot to associate useful information: cirio port, remote-terminal
port, remote-commander port, process ids & groups, user-provided label,
start time.

That would also be the place to stick the info that currently goes into
XrDBXInner.

Presumably Mach has a concept close enough to system-5 shared memory for
this purpose; is this true?

Date: Thu, 29 Mar 90 14:01:37 PST
In-reply-to: "Your message of Thu, 29 Mar 90 13:47:47 PST"
Sender: Mike Spreitzer:PARC:Xerox
Subject: Re: Do we need a world registry?
To: Howard E Sturgis:PARC:Xerox
Cc: Mike Spreitzer:PARC:Xerox, PCedarImplementors^:PARC:Xerox

Re:

"There is a general mechanism that has been used in the past for getting an agreement on port numbers for communication. If A wants to talk to B, A calls on B's machine using a wellknown port number, and requests a port number for the conversation. B's machine responds with a usable conversation port number, following this the interaction on the wellknown port is terminated. Further communication takes place on the conversation port. Why don't we use such a mechanism?"

The problem occurs when there are multiple Bs (e.g. Cedar worlds) running on one machine. In this case, the solution you mention has two shortfalls: (1) if A calls on a machine using a certain fixed port number, that cannot distinguish among the multiple Bs on that machine; and (2) which B is listening at that well-known port? (you want only one program instance pulling input from any source).

Date: Thu, 29 Mar 90 14:15:40 PST
In-reply-to: "Mike Spreitzer:PARC:Xerox's message of Thu, 29 Mar 90 14:01:37 PST"
Sender: Howard E Sturgis:PARC:Xerox
Subject: Re: Do we need a world registry?
To: Mike Spreitzer:PARC:Xerox
Cc: Howard E Sturgis:PARC:Xerox, PCedarImplementors^:PARC:Xerox
Reply-To: Howard E Sturgis:PARC:Xerox

Re:

The problem occurs when there are multiple Bs (e.g. Cedar worlds) running on one machine. In this case, the solution you mention has two shortfalls: (1) if A calls on a machine using a certain fixed port number, that cannot distinguish among the multiple Bs on that machine; and (2) which B is listening at that well-known port? (you want only one program instance pulling input from any source).



You are correct. So, use some variation on your proposal to obtain world numbers, but use the mechanism that I described to obtain a conversation port.

Howard

Date: Thu, 29 Mar 90 14:21:23 PST
In-reply-to: "Michael Plass:PARC:Xerox's message of 29 Mar 90 13:45:29 PST"
Sender: Mike Spreitzer:PARC:Xerox
Subject: Re: Do we need a world registry?
To: Michael Plass:PARC:Xerox
Cc: Mike Spreitzer:PARC:Xerox, PCedarImplementors^:PARC:Xerox

Is it true that when a PCedar world is terminated abnormally the slot would not get reset to look available? If that's so, it's not a big problem --- we could just require the user to manually invoke a command that we provide to smash a slot into looking available.

It would be nice if Cedar developers could add applications that listen on ports without a lot of administrative overhead; if the slots used a fixed layout, that layout would have to change every time a new application is created (or an application is changed to require more or different information in the slot). Using a property-list-like data structure in the slots could alleviate this problem.

As applications are added, and as improvements increase the amount of information an application needs, the fixed size of slots looks like a potential problem; could we just pick a large number and get away with it?

Mike

Date: Thu, 29 Mar 90 17:31:40 PST
In-reply-to: "Mike Spreitzer:PARC:Xerox's message of Thu, 29 Mar 90 14:21:23 PST"
Sender: Marvin Theimer:PARC:xerox
Subject: Re: Do we need a world registry?
To: Mike Spreitzer:PARC:Xerox
Cc: PCedarImplementors^:PARC:Xerox
Reply-To: Marvin Theimer:PARC:xerox

Even though it means running yet another demon process, we should at
least consider having a "Cedar" demon run on machines that acts as an
agent for all this information that been talked about. The advantage of
an active server/demon is that you can do network-wide monitoring a lot
easier that way. A server can keep/compute lots of statistics, both on
a continual basis and when asked to do so. For example, when we finally
get around to reimplementing our remote compute server capability, we'll
want to know what machines have running compute servers and what loads
they have.

Marvin.