AG Design
---------
2, July, 1996
-------------


Goal:
    To duplicate the MultiComAsyncGateway product on the Router box. This
    implies the following
	- Support for clients using MCSI sort of interface with its style
	  of dial-out port usage
	- Inbound calls support
	- Ability to use existing remote console programs as supplied by
	  the RNG product
	- Support for validation of users, etc
	- Online log of dial-out activity
	- Compatibility (perhaps) with existing configuration program

Can be divided into :

	- Init/de-init code individual to each portion
	- Basic core
		- send/receive on a session on the LAN
		- send/receive on a serial interface
		- serial programming
		- flow control
		- modem management 
		- periodic activities on queues?
	- Connection managment core
		- validating users asking for connections
		- setting up and tearing down connections
		- periodic acitivities
	- User database management
		- interface for a UI to maintain a list of users and access
		  permissions
		- code to support validation of users
	- Inbound calls support
		- support for setup of inbound activity
		- inbound calls server
	- Statistics support
		- Remote console support
	- Support for log of events


Some Coding Guidelines
----------------------
1. Don't use cryptic or shortened names. Use full names like in RouterWare
   code.
2. Don't include structures and globals from other modules. Instead provide
   interface functions in those modules to get required information. See
   the way RAS and WAN information is obtained.
3. Don't introduce globals unless they are absolutely essential. When
   introducing them, don't put them anywhere else other than the AG_CLASS
   structure.
4. Don't pre-allocated large arrays of structures. Instead perform dynamic
   allocation.
5. Make sure that allocated memory is de-allocated in all paths of code
   execution.
6. Make sure that a NO-DEBUG compile is done before shipping.


Decisions
---------
1. Interface to the network should be as distinct as possible so that
   other protocols can be coded to later easily. 
2. The server name used will be that of the router's name as configured
   in other sections. ??Need to obtain and keep this name??
3. Decided not to use the SOCKET interface and to code directly using the
   ECB interface. Socket interface involves an extra level of copying.
4. Decided to recode and not to reuse existing code.
5. Decided to introduce new serial side code. Easier than poking into the
   existing WAN chat code. Already that seems like a patchwork. Now there is
   serial support code in three places -- the original WAN driver, the WAN
   CHAT code and here. Also need to setup a mechanism to let others
   know that IPX dialout is in progress.
6. Now we go from CLEANING_UP line state to FREE, no RESET_MODEM inbetween
7. We will not use any XON/XOFF packets for flow control. PC based servers
   were using this because it was not possible to associate a session with
   IPX receives. In our case it is different. So now not issuing receives
   will automatically do flow control.
8. Removing the LISTEN_INBOUND line state. This actually does nothing and
   is always treated the same as FREE. We can know if a line needs inbound
   calls, by looking to the linked list of inbound waiting sessions.
9. All times will be 0 as there is no RTC in the box. If RTC built in,
   then implement the function get_current_date_time() and all time fields
   will show time properly.

Notes:
------
1. The IPX/SPX interface of RouterWare uses a ECB that always desires
   a single fragment buffer. Moreover this fragment should include
   MAC header, IPX header, SPX header and the data.
2. To know what MCSI request and response packets are possible, just
   look into AGMCSI.H.
3. Always the DESTINATION IPX ADDRESS IS PICKED FROM THE CLIENT ADDRESS
   THAT WE STORE WHEN POSTED IN THE LISTEN.
4. Before sending any header (any of the MCSI types) on the network,
   make sure you change information to inter (little-endian) format.


Session States
--------------
AG_SESS_CLOSED:
	Once a session entry is allocated, it is set to this state and
	a listen is issued. There is always one session entry in this
	state and the count of active sessions does not include this.
	This entry is the one that is listening on the network for
	a "establish connection" request.

	The only state change possible is to AG_SESS_ACTIVE when a
	connection is established.

AG_SESS_ACTIVE:
	Once a connection is established, the session enters this state.
	In this state, network receives are possible and all MCSI
	requests are handled.

	In this state, if needed, network receive calls are issued.

	On the following events, state changes can occur as mentioned.

	Event: Session aborted by client or SPX internally
	New state: AG_SESS_ABORTED

	Event: MCSI connect outbound request successful
	New state: AG_SESS_CONNECTED

AG_SESS_ABORTED:
	This is a temporary state during which the server waits for all
	pending network calls to get posted. Once all calls are posted,
	the session entry is discarded (memory is freed).

	On sessions in this state, network calls should not be made.

	During this state, the line_to_use field of the session entry
	is valid.

AG_SESS_CONNECTED:
	Once a line is alloted to a session (the line_to_use field of
	session entry is set value other than UNKNOWN_LINE), the
	session status becomes AG_SESS_CONNECTED. During inbound calls,
	the state may temporarily be changed to AG_SESS_CONNECTED for
	the duration of accepting passwords, phone numbers, etc.

	When in this state, network receives are issued if required.
	In addition, serial packets delayed and queued up are sent out.

	On the following events, the mentioned state is transited to.
	
	Event: Network aborts (internal, client or self)
	New state: AG_SESS_ABORTED

	Event: CD dropped on inbound
	New state: AG_SESS_CANCELLING

AG_SESS_CANCELLING:
	Temporary state during which all network calls are cancelled
	by the server. This then transits in timer to the AG_SESS_ACTIVE
	state. Maybe this state is not required...
	

	

