timr@labtam.oz (Tim Roper) (02/27/90)
The BroadcastQuery (and Query) packets could usefully contain the Manufacturer Display ID. This is to allow policies to be a function of the display. One such policy is for multiple xdm(1)s on the same network to decide whether to respond with a Willing or to ignore a BroadcastQuery. I know that the Request packet contains this information but suggest that this is too late. Consider a network containing two or more compute/file servers and some number of X terminals. Some of the terminal users want (and/or are allowed) to login to one file server and the other users to the other server. So xdm runs on both file servers. For convenience (ie. laziness) we want all terminals to use BroadcastQuery and to have xdm on the file servers to know, as a matter of policy, which BroadcastQuery's to respond to (with Willing). For example, we could use the existence of an entry in Xkeys. In the absence of this information and hence the ability to implement such policy both xdm's are responding to all BroadcastQuery's. If the wrong one is received first the subsequent Request packet is Decline'd (to to absence of an Xkeys entry) if XDM-AUTHENTICATION-1 is being used. If MIT-MAGIC-COOKIE-1 is being used the Request is Accept'ed but the subsequent user authentication fails (unless the user just happens to have an account on that file server). An example which is not a consequence of admitted laziness can be constructed by generalising the above example. On a given network there is a number of file servers any of which may be used by a certain class of X terminal (eg. student lab) and a number of file servers which may be used by another class (eg. staff terminals). The policy for the student file servers and terminals is to accept requests depending on load. So the student terminals use BroadcastQuery and wait for a Willing response from a student file server. with sufficiently low load. Because the staff file servers don't want to respond they would like to know which terminal is querying. We could have a mapping of IP address to Manufacturer Display ID and could even generate it from /etc/ethers given the -Ethernet-... scheme of assigning the IDs. But this is (a) ugly and (b) breaks down in the presence of dynamic IP address assignment. An alternative is for the X terminal to collect all replies to its BroadcastQuery and attempt a Request to each Willing host. Perhaps this is what was intended? (It is not what is implemented in the sample server, but that that is not definitive of course). -Tim.
keith@EXPO.LCS.MIT.EDU (Keith Packard) (03/01/90)
> The BroadcastQuery (and Query) packets could usefully contain the > Manufacturer Display ID. This is to allow policies to be a function > of the display. I'm assuming you're not implementing a display manager which refuses to talk to some vendors X terminals :-) The Manufacturer Display ID is used specifically to find the private key which the display uses to authenticate the manager. It was added for that purpose alone. This allows vendors which do not ship any sort of authentication scheme to avoid the complexity of programming each terminal with its Display ID. As the display manager receives the IP address of the display requesting management, it can make policy decisions based on that. I think this second scheme is actually more favorable than using the Display ID -- you could program the display manager to accept ranges of IP addresses and ignore other ranges; in this way you wouldn't have to reconfigure every display manager each time a terminal was installed/uninstalled. If you see some overwhelming advantage to using the Manufacturer Display ID instead of the IP address, please explain it to me. Xdm should support this sort of thing already; that it doesn't is because of limited engineering resources, not a desire to use some other mechanism. Keith Packard MIT X Consortium