scs_protocol.c

<B>Digital的Unix操作系统VAX 4.2源码</B>

 *		4. Request for termination of a logical SCS connection.
 *		5. Request for credit extension/withdrawal.
 *
 *		Processing of each request includes transmission of an
 *		appropriate SCS response.  The message buffer containing the
 *		received request is used to transmit the response.  The
 *		response can be immediately transmitted because the message
 *		buffer which contained the SCS request on the originating
 *		system has been reserved for reception of the corresponding SCS
 *		response.
 *
 *		There are five types of SCS responses:
 *
 *		1. Response to a connection request.
 *		2. Response to an acceptance request.
 *		3. Response to an rejection request.
 *		4. Response to a termination request.
 *		5. Response to a credit request.
 *
 *		Following processing of each response, its message buffer is
 *		used to transmit the next SCS request pending on the path.  If
 *		If there are no such pending requests the message buffer
 *		becomes the path's SCS send message buffer.
 *
 *   Inputs:
 *
 *   IPL_SCS			- Interrupt processor level
 *   lscs			- Local system permanent information
 *   pccb			- Port Command and Control Block pointer
 *   scsbp			- Address of SCS header of message buffer
 *   lk_scadb			- SCA database lock structure
 *   scs_cbvtdb			- CB vector table database pointer
 *   scs_listeners		- Listening SYSAP queue head
 *   scs_timeoutq		- SCS protocol sequence timeout queue head
 *
 *   Outputs:
 *
 *   IPL_SCS			- Interrupt processor level
 *   cb				- Connection Block pointer
 *	cinfo.cstate		-  Connection state
 *	cinfo.snd_credit	-  Number of send credits
 *	cinfo.status.cwait	-  SYSAP waiting for credits flag
 *	errlogopt.rreason	-  SYSAP/SCS connection rejection reason
 *   pb				- Path Block pointer
 *	pinfo.nconns		-  Number of connections
 *	pinfo.status.sanity	-  Sanity timer enabled flag
 *
 *   SMP:	The SCA database is locked for CBVTE allocation and CB
 *		insertion into the system-wide configuration database in some
 *		cases, or for CB removal and CBVTE deallocation from this
 *		database in others.  It is also required for traversing the
 *		queue of listening SYSAPs, for PB retrieval, and for PB removal
 *		from the SCS protocol sequence timeout queue.  Locking the SCA
 *		database also prevents premature PB deletion as required by
 *		scs_init_cmsb(), scs_request(), scs_response() and PD routines
 *		which both crash and open paths.
 *
 *		The CB is locked to synchronize access, for deletion in some
 *		cases, to prevent deletion in others, and as required by
 *		scs_log_event() in case logging becomes necessary.  It is
 *		indirectly locked through its CBVTE.
 *
 *		The CBVTE semaphore is incremented in certain situations prior
 *		to SYSAP notification and synchronized to in others.
 *		Incrementing the semaphore prevents any changes in connection
 *		state while SYSAP notification is in progress.  The semaphore
 *		is decremented after notification completes.
 *
 *		The PB is locked only when it is found necessary to update it,
 *		or remove the CB from the PB's work queue, or remove the PB
 *		from the SCS protocol sequence timeout queue.  This leaves the
 *		PB susceptible to path failure and even to a portion of the
 *		clean up which accompanies such failures.  However this never
 *		presents any problems because the PB is always protected
 *		against deletion by various mechanisms( SCA database lock, CB
 *		lock, CBVTE semaphore ) whenever such protection is required.
 *		PBs are always unlocked after the tasks requiring their locking
 *		have completed because many routines invoked by scs_receive
 *		explicitly prohibit any PB locks at the time of their
 *		invocation.
 *
 *		PCCB addresses are always valid allowing access to static
 *		fields because PCCBs are never deleted once SCS becomes aware
 *		of their existence.
 */
void
scs_receive( pccb, scsbp )
    PCCB		*pccb;
    register SCSH	*scsbp;
{
    register CB		*cb;
    register PB		*pb;
    register CBVTE	*cbvte;
    CMSB		cmsb;
    register u_long	notify_event = 0;
    CBVTE		*lcbvte = NULL;
    u_long		aborted_conn = 0, event_code = 0, semaphore = 0,
			status = ADR_SUCCESS;

    /* The steps involved in processing received SCS sequenced messages are:
     *
     *  1. Lock the SCA database.
     *  2. Lock and retrieve the CB targeted by the received SCS message.
     *  3. Determine whether the local SYSAP unilaterally aborted connection 
     *     establishment.
     *  4. Retrieve the PB over which the message was SCS received.
     *  5. Process the message according to message SCS type and current
     *     connection state.
     *  6. Optionally remove the CB from the system-wide configuration database
     *	   and deallocate it along with all associated resources.
     *  7. Unlock the CB( if locked ).
     *  8. Initiate transmission of an appropriate response or the next request
     *     pending transmission across the path.
     *  9. Unlock the SCA database.
     * 10. Optionally notify the local SYSAP of the occurrence of a specific
     *	   event on the connection.
     *
     * Steps 2-3 are bypassed for received messages containing connection
     * requests.  No local CB exists to be retrieved or to be checked for those
     * connection identification number mismatches which when associated with
     * the reception of specific types of messages signal unilateral connection
     * abortion.
     *
     * Little processing is required in Step 5 if connection establishment has
     * or is in the process of being unilaterally aborted( Step 3 ).  Steps 6
     * and 10 are also bypassed in such circumstances.
     *
     * Whether response or next request transmission is initiated( Step 8 )
     * depends upon whether the received message contained a request or a
     * response respectively.  This determination is optimized by the following
     * fact:
     *
     *		SCS requests have EVEN numbered message types while SCS
     *		responses have ODD numbered message types.
     *
     * Prior to initiation of next request transmission, the sanity check on
     * the appropriate path is aborted by removing the corresponding PB from
     * the SCS protocol sequence timeout queue.  This may be done because
     * reception of the response signals reception of the current request by
     * the remote SCS.  Note that the SCS interval timer is not unscheduled
     * even when there are no longer any ongoing SCS protocol sequences.  The
     * next invocation of the SCS interval timer routine discovers the absence
     * of work and "suspends" its own execution until there are SCS protocol
     * sequences requiring timing.
     *
     * CB removal and deallocation( Step 6 ) is dependent upon message
     * reception triggering of CB closure.  Local SYSAP notification( Step 10 )
     * is also dependent upon some event occurring as a result of message
     * reception and occurs through asynchronous invocation of the connection's
     * control event routine.  By optionally incrementing the appropriate CBVTE
     * semaphore before the CB is unlocked( Step 7 ), connections are
     * protected during such call backs against state changes.  The semaphore
     * is decremented upon completion of local SYSAP notification.  Whether the
     * connection requires protection is dependent upon both the event the
     * SYSAP is being notified of and the connection state.
     *
     * Steps 2-3 and 5 may uncover any one of the following error conditions:
     *
     * o The CB can not be retrieved.
     * o A connection identification number mismatch exists and is not due to
     *	 unilateral abortion of connection establishment.
     * o A message with an unknown SCS message type is received.
     * o The connection state is found to be inappropriate for the SCS message
     *   received.
     *
     * When one of these conditions is detected:
     *
     * 1. Message processing is aborted.
     * 2. The path on which the message was received is crashed.
     * 3. The message is returned to the appropriate local port free message
     *	  pool.
     * 4. All held locks are released.
     *
     * This course of action may seem to be drastic, but none of these
     * conditions is ever expected in a single processor environment.  The same
     * is not true for SMP environments where the occurrence of any of these
     * conditions is possible, albeit with an extremely low frequency, whenever
     * a path or local port fails.  This is because no mechanisms exist to
     * coordinate PD event notifications of SCS as there are mechanisms to
     * coordinate SCS notifications of SYSAPs.  This lack of synchronization
     * allows SCS sequenced messages to be received after notifications of path
     * failure even though PDs had initiated the former before the latter.  The
     * actions taken remain the same as in the single processor case even
     * though they are drastic and may well result in double crashing of path
     * or port.  There is no other alternative.
     *
     * The following table lists supported SCS message types and the processing
     * messages of each type undergoes( Step 5-6,8, 10 ) when one is received:
     *
     * SCS Message Type		Actions
     *
     * SCS_CONN_REQ		1. The PB is retrieved
     *				2. The path is opened( if not already open ).
     *				3. Search the queue of listening connections
     *				   for the target SYSAP.
     *				4. Allocate, initialize, and lock a CB for the
     *				   new logical SCS connection.  Set its
     *				   connection state to CONN_REC.
     *				5. Insert the new CB into the system-wide
     *				   configuration database.
     *				6. Initiate transmission of a SCS_CONN_RSP SCS
     *				   sequenced message containing an appropriate
     *				   status.
     *				7. Protect the listening connection while
     *				   notifying the local SYSAP of the request for
     *				   connection establishment.
     *
     * Failure to retrieve the PB( Step 1 ) or to open the path( Step 2 )
     * aborts the remaining steps.  The message is returned to the appropriate
     * local port message free pool and the connection request is forgotten
     * about.  The remote port eventually discovers the path does not exist
     * either through polling or through timeout of the connection request.
     * Failure to find the target SYSAP( Step 3 ) or allocate a new CB( Step 4)
     * forces bypassing of Steps 5 and 7 and transmission of an appropriate
     * error status in the response to the connection request( Step 6 ).
     *
     * SCS_CONN_RSP		- If return status == ADR_SUCCESS:
     *				1. Transition the connection into the CONN_ACK
     *				   connection state.
     *				2. "Wait" for the remote SYSAP to accept|reject
     *				   the connection request.
     *				- If return status != ADR_SUCCESS:
     *				1. Log formative connection termination.
     *				2. Close the formative connection.
     *				3. Remove the CB from the system-wide
     *				   configuration database.
     *				4. Deallocate the CB along with all associated
     *				   resources.
     *				5. Notify the local SYSAP of failure to
     *				   establish a logical SCS connection.
     *
     * SCS_ACCEPT_REQ		1. Update the CB.
     *				2. Log establishment of new SCS connection.
     *				3. Open the connection.
     *				4. Initiate transmission of a SCS_ACCEPT_RSP
     *				   SCS sequenced message containing an
     *				   appropriate status.
     *				5. Protect the connection while notifying the
     *				   local SYSAP of successful connection
     *				   establishment.
     *
     * SCS_ACCEPT_RSP		- If return status == ADR_SUCCESS:
     *				1. Log establishment of new SCS connection.
     *				2. Open the connection.
     *				3. Protect the connection while notifying the
     *				   local SYSAP of successful connection
     *				   establishment.
     *				- If return status != ADR_SUCCESS:
     *				1. Log formative connection termination.
     *				2. Close the formative connection.
     *				3. Remove the CB from the system-wide
     *				   configuration database.
     *				4. Deallocate the CB along with all associated
     *				   resources.
     *				5. Notify the local SYSAP of failure to
     *				   establish a logical SCS connection.
     *
     * SCS_REJECT_REQ		1. Log formative connection rejection.
     *				2. Close the formative connection.
     *				3. Remove the CB from the system-wide
     *				   configuration database.
     *				4. Deallocate the CB along with all associated
     *				   resources.
     *				5. Initiate transmission of a SCS_REJECT_RSP
     *				   SCS sequenced message.
     *				6. Notify the local SYSAP of rejection of its
     *				   connection request.
     *
     * SCS_REJECT_RSP		1. Log formative connection rejection.
     *				2. Close the formative connection.
     *				3. Remove the CB from the system-wide
     *				   configuration database.
     *				4. Deallocate the CB along with all associated
     *				   resources.
     *				5. Notify the local SYSAP of successful
     *				   rejection of the connection request.
     *
     * SCS_DISCONN_REQ		1. Synchronize to the CBVTE semaphore.
     *				- If the connection is OPEN:
     *				2. Prohibit further activity on the connection
     *				   by transitioning it to the DISCONN_REC
     *				   connection state.
     *				3. Abort any pending credit extensions.
     *				4. Initiate transmission of a SCS_DISCONN_RSP
     *				   SCS sequenced message.
     *				5. Protect the connection while notifying the
     *				   local SYSAP of the request for connection
     *				   termination.
     *				- If the local SYSAP has sent but not received
     *				  an acknowledgement of its disconnect request:
     *				2. Transition the connection into the
     *				   DISCONN_MTCH connection state.
     *				3. Initiate transmission of a SCS_DISCONN_RSP
     *				   SCS sequenced message.
     *				4. "Wait" for the remote SYSAP to acknowledge
     *				   the local SYSAP's request for connection
     *				   termination.
     *				- If the local SYSAP has sent and received an
     *				  acknowledgement of its disconnect request:
     *				2. Log connection termination.
     *				3. Close the connection.
     *				4. Remove the CB from the system-wide
     *				   configuration database.
     *				5. Deallocate the CB along with all associated
     *				   resources.
     *				6. Initiate transmission of a SCS_DISCONN_RSP
     *				   SCS sequenced message.
     *				7. Notify the local SYSAP of connection
     *				   termination.
     *
     * Synchronization to the CBVTE semaphore postpones processing of the
     * disconnect request and subsequent changes in the state of the connection
     * while call backs to the corresponding SYSAP are in progress.  Failure to
     * synchronize can lead to numerous aberrant situations in SMP environments
     * such as SYSAP notification of application message reception FOLLOWING
     * notification of its remote counterpart's request for connection
     * termination.  Semaphore synchronization is achieved by releasing the SCA
     * database and CB locks and re-obtaining them in the proper order until
     * all call backs have completed( CBVTE semaphore == 0 ).  Only open
     * connections require repeated synchronization attempts because only open
     * connections may have call backs to the corresponding SYSAP in progress.
     * Connection failure and termination due to path failure may occur during
     * a synchronization attempt between the time locks are released and
     * re-established.  When such failures occur:
     *
     * 1. All attempts to synchronize to the semaphore are immediately
     *	  terminated.
     * 2. The DISCONN_REQ SCS sequenced message is returned to the appropriate
     *    local port message free pool without processing the request.
     * 3. All locks are released.
     *
     * SCS_DISCONN_RSP		- If the local SYSAP has sent but not received
     *				  a request for connection termination.
     *				1. Transition the connection into the
     *				   DISCONN_ACK connection state.
     *				2. "Wait" for the remote SYSAP to issue a
     *				   matching request for connection termination.
     *				- If the local SYSAP has both sent and received
     *				  a request for connection termination.
     *				1. Log connection termination.
     *				2. Close the connection.
     *				3. Remove the CB from the system-wide
     *				   configuration database.
     *				4. Deallocate the CB along with all associated
     *				   resources.
     *				5. Notify the local SYSAP of connection
     *				   termination.
     *
     *
     * SCS_CREDIT_REQ		1. Update the CB
     *				- If credits are being extended:
     *				2. Initiate transmission of a SCS_CREDIT_RSP
     *				   SCS sequenced message containing the number
     *				   of credits accepted.
     *				3. Protect the connection while notifying the
     *				   local SYSAP of the availability of send
     *				   credits provide it had been waiting for such
     *				   notification.
     *				- If credits are being withdrawn:
     *				2. Initiate transmission of a SCS_CREDIT_RSP
     *				   SCS sequenced message containing the actual
     *				   number of credits withdrawn.
     *
     * When credits are being withdrawn, the available number of send credits
     * is never allowed to fall below the local SYSAP's minimum send credit
     * requirement.
     *
     * SCS_CREDIT_RSP		No required message type dependent processing.
     *     
     * While no message type dependent processing is required, the path is
     * crashed whenever a confirmation of credit withdrawal is received as
     * Ultrix never attempts to withdraw credits.
     *
     * More information about the SCS protocol sequences and the state changes
     * connections may undergo may be found by referring to the comments at the
     * front of this module.
     */
    Lock_scadb()
    if( scsbp->mtype != SCS_CONN_REQ ) {
	if( scsbp->rconnid.index > ( lscs.max_conns - 1 )) {
	    event_code = SE_BADCONNID;
	} else {
	    cbvte = Get_cbvte( scsbp->rconnid );