|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: R T
Length: 6905 (0x1af9) Types: TextFile Names: »README«
└─⟦b20c6495f⟧ Bits:30007238 EUUGD18: Wien-båndet, efterår 1987 └─⟦this⟧ »EUUGD18/General/Search/README«
Overview Search is composed of two parts - the daemon, and the player. The daemon does most of the work. He waits in the wings until someone connects to one of his two sockets (/tmp/slock or internet port 525). The action of connecting to one of the sockets wakes the daemon up, and when the proper information is recieved the new player is accepted into the game. A socket other than the default 525 may be specified in /etc/services or as an argument to searchd. This "request to play" is generated by the player process "search". If search is invoked without an argument, it is assumed that the player simply wishes to play on the local machine, and connects the player to the local (AF_UNIX) socket "/tmp/slock". An argument to search is considered to be a remote hostname the player wants to play on. Search will attempt to connect to that host's search daemon and to join play in the remote game. A port other than the one specified in /etc/services may be given to search as a second argument. Installation instructions: 0. If search is being installed by a non-superuser you will have to make a few changes to the procedure below. You must change the path names of the game and score file to something appropriate and also choose an internet port number which is not in the reserved range. See the variables LIBDIR, OWNER, GROUP and ROOT in the Makefile. The search daemon will have to be given this port number as an argument and the users will have to give it as an argument to search itself. (You could instead just change DEFAULT_IN_PORT in defines.h if you are putting up search as a non-su on a local network. All of this about port numbers is of course irrelevant if you do not use -DINET.) 1. Decide if you wish to have the internet feature of search. This is the feature that allows people from other machines to play search without having to do a remote login, etc. If you decide that this is a bad thing, or you don't have network software (i.e. no network), remove the -DINET from the Makefile. 2. Compile all of the modules by running "make". If you're really running 4.2 BSD it should all work correctly. 3. Run "make install", which will create all the score files, and move everything to its proper location. The daemon must have read and write access to the score files, (if not run as root at boot time). 4. If you would like the search daemon to be started at boot time as are the other system daemons, place an entry in /etc/rc.local that looks like this: if [ -f /etc/searchd ]; then echo -n ' searchd' >/dev/console /etc/searchd (Note that if your system clears /tmp AFTER starting searchd, the AF_UNIX socket /tmp/slock will be deleted. The default Vax 4.2 /etc/rc will do this!) 5. If you are using the "internet" feature of search, add an entry to /etc/services that looks like this: search 525/tcp searchd # inter-machine search Make quite sure that this entry number (525) is not being used on your system for any other purpose (i.e. no other entries with the same number). How Search Works. The entire i/o of the game is transmitted over stream socket lines. The screen output comes from the daemon, through the stream socket to the player, and then to the screen. The commands come from the player to the daemon via that same stream socket. There is one connection (i.e. one file descriptor at each end) per player in the game. This means that the upper limit on the number of search players depends on the maximum number of files open at once. Score is kept by the daemon, and the score file is updated by it also. This results in a slight delay when a player exits the game, but since the players can come from remote machines, it is necessary that the daemon do the score file updates. Should the daemon terminate for any reason, it is possible to look in a file of errors that the daemon keeps. While many of the entries in this file will not be errors, it should give some sort of reason why it died. This file is (on our system) "/usr/games/lib/search/errlog". If it at any time becomes necessary to kill the daemon, please do so with "kill -INT pid", as this will let the daemon "clean up" after itself. Be warned that with medium to high load averages, playing is extremely poor since screen updates come more and more slowly. It's been my experience that search is only playable when the load is below 6 (on a vax 780) or below 4 (on a 750). Failing this, you can always have some friendly super-user renice the daemon, and then have fun! Also be warned that playing search at low baud rates gives the player a great disadvantage, since the screen output comes in faster than it can be displayed. Under the current version this will cause jerky response for all players as the daemon's writes begin to block. If you access a michine over a network, and then play search over the network, all I/O will get repackaged at each step and it can get hard to hit your target. As a handicap for good players, the use of several rlogin links is possible. Most of the '#' aliens have been removed from the game (to increase performance), but left most of the shankers '@' in (since they shoot back). For those of you that remember the old game, there is no such thing as a "virgin" in this version, neither does the program keep track of the "scab" status from game to game. The score file print routine is unbelieveably primitive (compared with the original Greg Ordy cranked out). Scores are kept by the name of the player - if from a remote machine, that machine's name is also included. Some code was put in the exit routines to try and keep "LAST_ACK" and "FIN_WAIT_2"'s to a minimum (see the command "netstat"). Otherwise, all entrances and exits from search invariably generated LAST_ACK's and FIN_WAIT_2's (which look really messy). There is a one line kernel fix that gets rid of most of them, but offhand I don't remember what it is (I know, big help). Porting Search Search depends heavily on the 4.2 inter-process communication scheme. Porting to other operating systems will be major work. (Volunteers?) Search uses functions with variable numbers of arguments but does *NOT* use varargs.h yet. Since it runs on Pyramids as is, this is a low priority. Most of the other lint has been removed. Search also needs signed chars. When we bump into a system which doesn't have them, something will have to change. Search uses temcap but not curses. Padding is totally punted. If you need to put padding in, look in search.c. If you have bugs or suggestions, send them to /dev/null. Just kidding. Send them to Matt at the address below. Dave Pare <ucbvax!sdcsvax!mr-frog> or <ihnp4!sdamos!mr-frog> April 1984 Amended by Matt Crawford <ihnp4!oddjob!matt> or <crawford@anl-mcs.arpa> or <matt@uchicago.csnet> or <x1.crawford@uchicago.bitnet> July/August 1985