Server Beacon
-------------

ServerBeacon class
	-- Has the main() method
	-- Handles all the necessary setup to get the desktop
	computer on which it's running to broadcast the appropriate
	information.
	-- Reads in a file named by the first command-line argument.
	-- Converts the information in the file to a byte array, then
	instantiates and starts a Broadcaster with this byte array as a
	parameter.

Broadcaster class
	-- Extends Thread class.
	-- Constructed with the byte array that will be broadcasted over
	802.11.
	-- Has constants BCAST_ADDR, MIN_WAIT, MAX_WAIT, and PORTNUM.
	-- run() method has main loop that goes forever until an IO
	exception occurs.
	-- Each loop iteration, send datagram broadcast with the byte
	array information and play special wave file.
	-- At end of loop, sleep beteween MIN_WAIT and MAX_WAIT amount
	of time.

Mobile Client
-------------

MobileClient class
	-- Has an UltrasoundListener class, which has an
	UltrasoundDetector class.
	-- Will decide when to listen for ultrasound based on the
	reception of 802.11 broadcasts.
	-- Associates 802.11 broadcasts with ultrasound detections,
	deciding the location of the device.
	-- Will not be a thread class or contain a main() function, but
	will have a beginPositioning() method that starts a thread.
	This thread will constantly listen for 802.11 broadcasts.  When
	it finally receives something, it will invoke a callback method
	in the MobileClient class that does something with the data in
	the 802.11 broadcast.  It needs a reference to the MobileClient
	object that instantiated it.
	-- Have callback method for beginPositioning thread that maybe
	sticks room data onto a queue, then starts listening for
	ultrasound.  Or maybe don't stick room data onto queue, just
	start listening for ultrasound, blocking the beginPositioning
	thread until a decision comes in from the UltrasoundListen
	method, thus preventing the reception of another 802.11 message
	until done listening for ultrasound.
	---- 1) Have two threads: the 802.11 message listener described
	above and an ultrasound listener.  The ultrasound listener will
	just keep handing ultrasound detection events to the
	MobileClient class as the 802.11 message listener is handing
	802.11 message receive events to the same class.  All of these
	events will have timestamps.  It is then the job of the
	MobileClient class to correlate the ultrasound detection events
	with the 802.11 message receive events.
	---- 2) Have neither of the above mentioned threads, but have
	the MobileClient class itself be a thread.  In this thread's
	run() method (which loops forever), sequentially listen for
	802.11, then listen for ultrasound for a specified period of
	time.  If ultrasound was heard, depending on debouncing
	techniques, can call the external application's room updated
	method (if room changed).  Or could wait until get three
	positive identifications in a row before calling external
	application's room updated method.  Or could use certainty
	technique described below.  This thread is blocked while
	waiting for the ultrasound.
	-------- After receiving 802.11, could immediately call another
	thread so that can receive another 802.11 while first thread is
	still listening for ultrasound.  This thread would then not be
	an infinite loop, but would just go through the sequence once
	and stop.
	---- 2b) Have MobileClient class not be thread or have main()
	function.  The class be similar to that in suggestion 1 above,
	but have threads similar to those mentioned in suggestion 2
	above.  beginPositioning() will launch the first thread.  This
	thread blocks on listening for 802.11.  Once it receives 802.11,
	it calls MobileClient class's beginPositioning() method again
	then begins listening for ultrasound.  After receiving binary
	ultrasound decision, it calls MobileClient's update() method
	with this boolean value and the 802.11 message.
	-- Have reference to external application that instantiated
	MobileClient object because external application needs to
	register as a listener of room updates.
	-- Call external application's roomUpdated() method whenever a
	room change occurs.  This occurs at end of callback method for
	beginPositioning thread.
	-- Have some percent certainty that starts out small as a person
	enters a room, increases as more determinations indicate that
	room, and decreases with false identifications.  Perhaps this
	could freeze after it exceeded some threshold.  Two or three
	identifications in a row would be required to change this
	determination.