[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Mon, 28 Aug 89 12:54:07 EST
Could someone please explain to me the following behavior?
I have this form in my lispm-init file so that terminal
windows will default to SUPDUP over TELNET.
(let ((protocol (neti:find-protocol-named :supdup)))
(setf (neti:protocol-desirability protocol) 0.9)))
Now if I login or just load file lispm-init my terminal windows are
still TELNET. However, if I load lispm-init into the editor and compile
the above form, then the terminal window becomes SUPDUP.
Well, this stuff is pretty complicated, all right. Let me see if I can
elucidate things for you, and maybe you can figure out what the problem is.
1. The Terminal window doesn't "become" SUPDUP or TELNET. The protocol
chosen by default is the "best" one, which calculation is extremely
2. You can control which protocol is used by supplying the :Connection
Protocol keyword to the connection command; your window should look
Connect: HOST (keywords) :Connection Protocol SUPDUP
Type a space after the host name to see what else you can say.
The "Best" protocol is the one with the highest overall desirability.
Desirability is calculated as (essentially) the product of three numbers
between 0 and 1, namely the desirabilities of the network, the protocol,
and the host itself.
The network is sent the :DESIRABILITY message, and gets to take the actual
host into account. For CHAOSnet connections, for example, UNIX hosts are
devaluated by 10% over non-UNIX hosts, and the "distance" to the host (the
number of times the packet must be forwarded) is also taken into account.
Typically, CHAOSnet connections' desirabilities are 0.8 for non-Unix, and
0.72 for Unix hosts. Internet connections are always 0.95.
The protocol desirability is provided more-or-less statically, as you have
apparently discovered. The variable you are changing is in fact the
The host desirability appears to be based on factors which don't change
between different protocols, from what I can make out from the code
(different services, yes; different protocols, no). Thus, this factor
shouldn't make any difference (it's used to determine which of several hosts
should be tried first for services where you don't care exactly which host
provides the service, like STORE-AND-FORWARD-MAIL service).
So, here's some homework for you to do:
1. Make sure your init file is actually changing the desirability as you
expect. Try this:
(neti:protocol-desirability (neti:find-protocol-named :supdup))
You may have inadvertently commented out the form in your init file.
This form should evaluate to 0.9, if you've done things correctly.
2. Assuming your init file really is doing what you think, try this:
(net:find-paths-to-service-on-host :login (net:parse-host "host-name"))
(mapcar #'neti:service-access-path-desirability *)
This will tell you what the actual desirabilities are.
Here are my three suggested theories for what's happening:
1. You have the form commented out. Look around for mistaken #+...,
#-... and #|...|# kinds of commenting-out. The editor command c-sh-M
(macro expand) can be pretty useful for this kind of examination.
2. You are trying to use the Terminal window to two different hosts. One
of them doesn't have the SUPDUP protocol in its advertised services.
Add the service LOGIN CHAOS SUPDUP or LOGIN INTERNET SUPDUP as appropriate.
3. You are trying to use the Terminal window to two different hosts. One
of them is a CHAOSnet Unix with the following LOGIN services:
LOGIN INTERNET TELNET
LOGIN CHAOS SUPDUP
LOGIN CHAOS TELNET ;; optional, doesn't change things
This is the host which doesn't work, even after you change the SUPDUP
protocol desirability, because
(* 0.72 0.9) = 0.648 ;; The SUPDUP via CHAOS to UNIX host desirability
(* 0.95 0.7) = 0.665 ;; The TELNET via INTERNET desirability
If this is the case, add LOGIN INTERNET SUPDUP to your host; that should
fix the problem without your patch above (you shouldn't need to mess with
the protocol desirabilities at all, since the default for SUPDUP is 0.8
and for TELNET is 0.7).
The "how to fix it" suggestions above are implemented using the namespace
editor. If you are finding these hosts via the Domain software rather than
the Namespace software, you will need to update that database instead.
Update a record called "well-known services" in the domain database for the
host. Of course, this data is cached in your local machine as well, so you
will probably need to boot your machine after getting the Domain software
updated (for Namespace updates, changes you make locally get incorporated
immediately and changes you make from one machine can be obtained immediately
on another machine by using the "Show Namespace Object" command).