The EVAL Server -- A PUP Network Inter-Communications Facility forInterlisp-DFile:EvalServer.pressRevised: Feb 21, 1983, by JonL WhiteThe file EVALSERVER.DCOM contains routines to facilitatecommunication, over the EtherNet, between two or more D-machinesrunning Interlisp-D. In simple usage, one or more D-machines(Dolphin, Dorado, or Dandelion) are started up with "servers"running, and a "client" of the service merely requests (via theethernet) that a server EVALuate some form, and return the results.A user may direct his "remote" evaluation request to a specificserver, or may broadcast it on his directly-connected network; inthe latter case, at most one of the servers will be given thego-ahead to perform the service, but there are plans for futureextensions to permit results from many servers for a broadcastrequest. (Likely a request for service will be coupled with afunction to be applied to any results that come back). These routines work most conveniently when the multiple processmechanism is enabled (see Proc.press), but functionquite adequately without it; additional hints will be given at theend of this note for those who cannot have the process mechanismenabled, but who would like to have two Interlisp-D's talking toeach other.Starting up the "server" sideThe function call (EVALSERVER )will initiate a background process named "EvalServer.Listening"(of course, this will be a "foreground" process, if the multipleprocess mechanism isn't enabled). All arguments are optional, andhave the following meaning: -- if non-null, will run the service foronly the number of minutes specified; otherwise it will runindefinitely. - - a list of ether host names (or numbers) whomthe server is willing to service: if T is on this list, itwill service any request addressed to this specific host(called, "flirtatious" mode), if NIL is on the list, it willservice any request broadcast on the connected network (called,"promiscuous" mode). Default for this list, NIL, is convertedinto the union of "flirtatious" and "promiscuous" modes. -- a list of hosts for whom service will notbe performed; NIL on this list means no service for broadcastrequests; T on this list means no service for "myself" (i.e.attempts by some process running concurrently on the serverhost to send a "remote" evaluation request to the same host,will be rejected).In any case, the global variables EvalServerClientHosts andEvalServerGaggedHosts will be dynamically consulted for the sameinformation; this is so that you may tailor the client screeningprocess while the server is running. The "gags" always haveprecedence over the "hosts" lists.EVALSERVER.TTY21-Feb-83 23:06:55Page 1 aB!` ]l [wlX]8 V@ UC= S= R)@ PC O? MA K= Jh@ H> GN> E8B? A> ?C >@ L#; L"8 L < L? Lo? L8 U? L= L;< L; L!< L ; z@ @ `< "h. "Et y;^fWhile the server is running, a call to(EVALSERVER.ABORT )will stop a currently running process, such as one that is in aloop, or that is "poaching" more time off the server than isdesireable; see below under EVALSERVER.STATUS for a definitionof the identification terms. may be either an integer, the "identification"number of some service, or a cons of the id number and thehost; the "cons" form may be required if there are two or moreservices, from separate requesting hosts, with co-incidentallythe same id number. permits recording why a service was stopped; it isoptional, and the default recording is "Aborted Locally byError/Quit". is optional, and if non-NIL, will cause an ERROR tooccur if there is no transaction as specified by or of the transaction seems to be wedged.While the server is running, a call(EVALSERVER.STATUS )will return a list of information associated with the state ofcurrently-running services, already-completed services, andrequests still in the input queue. A "service" is identified by acons of a transaction number and a host number; the transactionnumber is in fact the packet id in the PUP used to communicateover the EtherNet (a similar idea will eventually be used when theserver is implemented in NS protocols). -- selects one or more of the informationlists to be output, as follows: DONE (or COMPLETED or FINISHED) adds in the remnants of thelist of completed services (which list is pruned down fromtime to time by the "cleanup" process mentioned above. Aglobal variable, \ES.PURGEINTERVAL.SECS, controls thefrequency of the "cleanup" actions, and also the maximumtime for which old completed service records are kept); RUNNING (or CURRENT) adds in the data for currently executingevaluations requests; INPUT (or INPUTQUEUE) adds in the data for PUP's still waitingfor service. T acts like the union of DONE and RUNNING; ALL acts like a union of all three of DONE, RUNNING, andINPUT; NIL, and no argument, default to same as ALL. -- if non-null, then only records with thatidentification number will be included in the result. Similarly, a call(EVALSERVER.STATUS.WINDOW )will put up a window which continuously monitors and displaysthe above information. The middle mouse button is active in thisstatus window to delete the various items; deleting a RUNNING orINPUT request is the same as calling EVALSERVER.ABORT on it.A trace facility may be enabled/disabled by a function call:(EVALSERVER.TRACE )where, if non-null, enables traceing; disables if null., if non-null, should be a "region" and marks a regionfor the trace window; if null, the user is prompted to "mouse"EVALSERVER.TTY21-Feb-83 23:06:55Page 2 c8& a9 `? ^< ]> [w Y< LX]: LV> LUC> LS R)@ LP: LO M> LK> LJh) E# D4* B> A; ?B >@ &%0,#8" . t1o6  U, = ;B A !< z< ! ` 7 F> L>h. "Et  y:8^fa region.Both the left and m idle mouse buttons are "active" in the tracewindow: LEFT toggles a "flg" which turns traceing on or off, andMIDDLE does a quick clear of the trace window.The Client: Using a remote Eval ServerThe basic use of EVAL at a remote host is invoked by:(REMOTEVAL
)The S-expression is shipped via the ether net to the host, where it is EVALuated by an EvalServer and shippedback If is NIL or 0, then the request is not directedto a partricular server, but is merely broadcast on the network; ifany server is willing to service such a request, then it will"handshake" with the requestor and do so. If the remote evaluationcauses an error, then that error will be "brought back" locally,and an error will result which will incorporate the remote message(of course, the stack and environment of the remote host is not"brought back"). A current limitation is that the PRIN4 form of , and that of the result, must fit within one PUP -- about 530 bytes. The argument can currently be only either 0or 1 (NIL defaults to 1); if 0, then the REMOTEVAL function willnot wait around for the result from the remote host, but willreturn as soon as there has been an acknowledgement that theservice is being performed; its value in this case will be theidentifier number use for that transaction. This is especiallyuseful when invoking a lengthy task which is done primarily for"effect" rather than value. Also it may be usefule when "broadcasting"some evaluation which will later directly send a note back to theinitiator; thus there is no need to go through the several "handshake"packets, and general "broadcast" time-consuming protocols.Also,(REMOTEAPPLY )invokes a similar remote use of APPLY (as opposed to EVAL)Perhaps one may want to see how some server is progressing on itstasks: (REMOTEVAL '(EVALSERVER.STATUS 'ALL) ) will get the list documented above. If one decides to cancel somerequest, then (REMOTEABORT ) provides a convenient entry into the EVALSERVER.ABORT function atthe remote host. is either an id number, or a cons,as described above for EVALSERVER.ABORT; however, if only the idnumber is given, it is cons'd with the local host number beforesending to the server.If a lengthy computation is initiated on a server which is notrunning multiple processes, it would be a good idea for it to checkthe input queue from time to time, say by (EVALSERVER.STATUS'INPUT), and explicity call (EVALSERVER 1)when there are waitingrequests; for it may be that one of these waiting requests is anabort for the current process. Consider the example below, whereEVALSERVER.TTY21-Feb-83 23:06:55Page 3 Lc8 a@ `@ ^/V& R)5 P5 O@ M@ KC JhC H= GNC E@ D4B B? AI ?E 4? 3%? 1H 0 A .~F ,: ) t(J@ &: "A  / oC  U) A ;B @ !?  z> C `= @ F@ Bh. "Et  y=^feach time through the PROG loop (which is being sent for remoteevaluation) there is a check for possible inputs, and a short callto EVALSERVER from that code itself, to insure that subsequentcalls will have a chance to run.74_(REMOTEVAL '(PROG ((CNT 0)) LP (DISMISS 10000) (add CNT 1) (AND (EVALSERVER.STATUS (QUOTE INPUT)) (EVALSERVER 1))(GO LP))'PLAZA 0)5575_(REMOTEVAL '(EVALSERVER.STATUS 'ALL) 'PLAZA)((Completed.Transactions: ((ID#.ClientHost: 54 BuickoSaurus) (HowStop.#Seconds: COMPLETED 127)))(CurrentlyRunning.Transactions: ((ID#.ClientHost: 56 BuickoSaurus) (Process: RUNNING)) ((ID#.ClientHost: 55 BuickoSaurus) (Process: RUNNING))))77_(REMOTEABORT 55 ' PLAZA)ABORTEDNote that the transaction id for this "lengthy" process wasreturned by the call to REMOTEVAL, since we requested no waitingaround for the result (third arg of 0). Then when the remoteEVALSERVER.STATUS was done, both that transaction, and the oneactually causing the evalserver status to be read, show up as ID's55 and 56. A subsequent remote abort for number 55 will stop it,and leave a record that it was remotely aborted. Of course, thisis not necessary if the EVALSERVER is running under thePROCESSWORLD.Some Implementation Details:The semi-well-known socket number 668 is used for receiving evalservice requests.EVALSERVER.TTY21-Feb-83 23:06:55Page 4 c8? aB `? ^ t[w Y X]V UC'SR)PO tM tJh/ tHGN#\E# LD4B#\A?#\> t: t9Y 6?< 4@ 3%= 1> 0 B .~B ,B +d7 ) " @ oh. "Et> !/7HGACHAEVALSERVER. gffg0g^gpgqgMg^gPgTȽgkpgr¶ȶgvpgkg}gkgp2gg^gvgzLgggggB oϓoh/ gg"h)oW EMPRESS.RUN9,9,| gxh;@x9,g߾.9,gggg (-H C>@j/$EVALSERVER.PRESSGACHAEVALSERVER.TTYfJonL.PA!21-Feb-83 23:06:55