DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - download
Index: ┃ R T

⟦b58812d39⟧ TextFile

    Length: 7144 (0x1be8)
    Types: TextFile
    Names: »README«

Derivation

└─⟦87ddcff64⟧ Bits:30001253 CPHDIST85 Tape, 1985 Autumn Conference Copenhagen
    └─ ⟦this⟧ »cph85dist/search/README« 

TextFile

                          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

----------------------
PS: Note from compiler of tape: diku!kimrp

850820 : Has run patch on search, but it failed on util.c.
	 All .orig and .rej files kept.
850822 : New patch for util.c has been done. The util.c.rej
	 file is removed.