TCP/IP |  Assignment 2 (chat-client/server)  | Due according to syllabus
------------------------------------------------------------------------

The goal of the 2nd assignment is to code a TCP client and server combination
with a protocol designed by you.

In particular we want to do a simple-irc service that we will call "blah".
There should be a blah client and a blahd server.  In addition there
will be a small "oracle" capability in the server; i.e., the server will answer
certain queries with moronic answers (well they could be really intelligent
funny answers, but we leave that part up to you). 

The blah service has 3 conceptual parts.  

	1. a blah client cleverly called "blah"
	2. a blah server cleverly called "blahd"
	3. a facility in the blah server that when properly addressed with
	both an invocation and question may randomly answer the question.  
	On the other hand one might embed debugging commands here.
	We will call this function the "blah oracle".

Architecture:

		blah client/server code
		---------------------------------------
		blah protocol mechanism
		-----------------------
		TCP socket calls

------------------------------------------------------------
The client user interface should be invoked as follows:

(shell) blah server_ip/DNS server_port

server: you are connected to blahd on system X at port Y

The blah client should then login to the server with no authentication
and should present a prompt to the user.  At this point the user
is not able to chat with other users but has merely connected to
the server.  Any attempts to make anything happen here should receive
an error message from the server on the order of "please first join a channel".

(blah)  hello hello

please first join a channel

At this point the user may JOIN a "channel".  We can define a channel
as a set of possible users.  A channel is simply a string.  A user
can only join one channel at a time and must exit the server completely
to join a different channel.

(blah) join <channel-name> 

channel-name is a string.  You should explicitly and clearly define the
nature of the string.  The client should send a message to the server
on the order of "JOIN string".

The server should reply with either an OK message or an error message
as appropriate.  Server messages should always be displayed.

(blah) some message 

At this point you can type in messages.  The server must forward this
message to any other clients connected to the same channel.  It must
NOT forward this message to any other clients connected to different
channels.  Messages between client and server should be sent as follows:

	"PRIVMSG string"

However

(blah) #oracle-command or message

Any message that begins with a # (hash character) should be sent to the oracle
function in the server.  This may be a simple command for the server to do something
(i.e., useful for debug purposes).  Your oracle might be a random idiotic oracle however.
E.g., you could say:

(blah) #how are tricks oracle?
"oracle sez: The rain in Portland is very tiresome".

What you do with the oracle is up to you.  You must however have one.

Finally you must be able to quit the blah client.  Cntrl-D will work here.

------------------------------------------------------------
Protocol notes:

	Obviousally one must specify the format of what a client sends to
	a server and what the server returns to clients in a protocol.txt
	description document.  Be very precise here as this will be a very
	important item to be graded.

	Roughly you should have 

		a JOIN message
		a PRIVMSG message
		an ORACLE message

	The server should always return something.  Note that with PRIVMSG messages,
	the server must forward the input string to all other clients logically
	attached to a channel.  In general the server should ALWAYS return a message
	be it an acknowledgement message, error, or information.  This may be coded
	as a binary structure passed back and forth or via an ASCII-string based
	protocol as with the real IRC, FTP, HTTP, etc. 

------------------------------------------------------------
Server notes:

	A server is not expected to talk to other servers, but only to clients.

	A server must maintain a logical channel abstraction, thus there can be more
		than one "chat-room" with a server.  However the set of channels
		can be finite (at least two).

	A server shall have a special oracle command facility lurking in it.  
	You need to define what the oracle does in your architectural description.

	A server must work with multiple clients and must be a master/slave TCP server.

	The server should exit upon receiving a SIGHUP or SIGINT signal.

------------------------------------------------------------

Turn in at class (see syllabus for due date):
	1. src listings 
	2. makefile
	3. script output 
		roughly show your test plan as captured
		with script (or printfs) via client side runs.
	4. architecture description
		describe in ENGLISH the overall implementation
		of your protocol. This is an important part
		and will be the first thing the instructor/grader
		reads. Be sure and justify your decisions.
		Explain 
			1. the blah protocol, 
			2. the client/server architecture and mention any local o.s. system
		calls used.
	5. test plan
		This should consist of a set of test cases 
		where you list each test, describe what it does, 
		and describe what results you expect.
		Your script output should reflect a run of
		your test plan.  You may put tests in the
		test plan, that you cannot execute. Justify
		them and clearly state that you cannot execute
		the test.

ALSO turn in all of the above via e-mail to the instructor or grader
as a shar listing.  You turn in two things. 1. printed version
at class. 2. email version using shar.  The shar email version will
be used for deciding lateness.