Notes:

-------
This distribution now includes some prototype code for interfacing
IBM's Net.Data to isect's IO library.  From within Net.Data macros,
programmers can now call isdLogin, isdSend, isdRecv, and isdLogout.
I'm not experienced enough in Net.Data programming to know if I've
defined the interface in the most optimal way.  If you are and you
have some suggestions for how it can be better implemented, please
send me an email.
-------

Building Isect also requires GNUMake.  I tried building it on an AIX box
without it and it wouldn't configure.

Questions and comments should be mailed to tgagne@ix.netcom.com

Configuration:

alias one of the hosts in /etc/hosts to 'isectd' and start isectd there.
Add the following to /etc/serivces:

#
# isect services
#
isectd		5501/tcp	# isectd
isdexec		5502/tcp	#isdexecd

The port number you specify should not conflict with any
others that are reserved.

To check if things are running:

cd demo/
isdexecd &
isectd &
isdclient < isectd.conf
isdclient -c 'workers'
isdclient -c 'hello' isdecho
isdclient -c 'workers'

WARNINGS:
	We're still working on the OS/2 port

	isect won't compile using the standard HP-UX compiler due to
	ANSI prototypes not being accepted.  I'm working on that.

1.0.1 RAMBLINGS:
	I'd like to begin using functions like inet_addr() but I'm 
	unsure how to check for them in configure.in.  Should I look
	for them in include files, libraies, or just as simple functions?

	I'd like to add a port-number parameter for clients to use
	when logging in.  This would be useful on systems were people
	using isdclient can't get /etc/services changed.  Problem is,
	even though the number could be passed to isdLogin() which
	would send it to isdAttach() which would use the correct value
	for isdConnectTo(), that parameter is used by clients to specify
	which *service* their attaching to.  It's used by workers to
	specify a port number.  Sigh.

	Another problem exists if I want to password-protect isectd.  Somehow
	the password needs to be passed in isdBadge{} but there's no room
	for it in the current definition.  We could try lengthening it or
	having isectd request it from the client somehow.

	isectd can hang waiting for a client or worker to send a badge.
	This is a bad thing.  I think there's a timeout.

	Something that's commonly needed is an alarm in the worker.
	Many workers can potentially hang outside their control (I've
	written a few that if a bad question is asked a datafeed, they'll
	wait for days).  One solution would be to set a timer so that the 
	worker will only spend x wall-seconds working on anything before
	abandoning it.  This could be worked into the library with a longjump
	to something but I'm unsure that would be very portable.  
	Maybe it would be possible for isectd to do something a little more
	forecful, like shutdown the fd and treat the worker as hung and
	try replacing it with a new one.

