Writing a server using 4.2 ipc

[Heather Klapman]

I would like to find out how to write a robust server using 4.2 ipc.
The application is thus:
	We want to monitor our terminal usage such that if all terminals
	in our labs are being used, students without a terminal can
	signup with a 'terminal server' program and be granted the
	next terminal that is available.  Our terminal server is
	made up of 4 programs that talk to each other via ipc:

	The Queue Manager:	this services all requests having to
				do with terminal queues and keeps
				info about terminal availability
	The Display Manager:	this provides the user interface portion
				where students actually make requests
	The Utmp server:	this polls the utmp files and notifies
				the Queue Manager of changes
	The Login shell:	this queries the Queue Manager to find
				out whether a student is allowed to log in.
The Problem:
	Currently, if one of the 3 processes that converses with the
	Queue Manager drops out of the conversation before using the
	internally defined) Goodbye' protocol, then the Queue
	Manager hangs--netstat shows it in FIN_WAIT_2 state.  An example
	of where this could happen in normal operation is where the
	querying process is on a site remote from the Queue Manager 
	process and that site dies.
	
	A solution in most cases would be to always have the Queue
	Manager fork a child to take care of requests (like the inetd
	program does).  However, I don't see a way to do that here
	because the Queue Manager has to maintain knowledge of its
	internal queues and the requests must be serviced serially
	so that everyone gets up-to-date information.

	Another idea is to have the Queue Manager set an alarm and
	check once in a while to see if it's in FIN_WAIT_2 state
	and if so, reset itself via some magic.  If this is feasible
	(is it?) then how can the Queue Manager efficiently detect 
	whether it is in this state.

Any ideas?

					Heather Klapman
					UCLA Programmer