rfc1085.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      - flushes the serialization module, and

      - releases TCP or UDP resources

   Following are the interpretation of and the defaults assigned to the
   parameters of the P-P-ABORT service.




Rose                                                           [Page 13]

RFC 1085               ISO Presentation Services           December 1988


      1. Provider reason

        An integer code detailing why the connection was aborted. Codes
        include, but are not limited to: invalid PPDU parameter,
        unexpected PPDU, unrecognized PPDU, and specified reason.

      2. Abort data

        None.

9. Information Transfer

   Although the Information Transfer facility consists of many services,
   only one, the P-DATA service, is provided by this memo.

9.1. The P-DATA Service

   This services provides the service user with a data transfer
   capability.  This service has effects which are sequenced and non-
   destructive.

   If the udp-based service is selected, then there is an upper-bound on
   the size of the serialized ASN.1 objects which may be transmitted.
   This limit, imposed by the UDP, is 65536 octets.  As a practical
   matter, it is probably a good idea to keep datagrams less than or
   equal to 536 octets in size.

   For our purposes, the P-DATA service:

              - sends user data

   Following are the interpretation of and the defaults assigned to the
   parameters of the P-DATA service:

      1. User data

        A single ASN.1 object is present, a remote operations APDU,
        carried in presentation context 1.

10. Elements of Procedure

   The service provider is in one of the following states:

           IDLE, WAIT1, WAIT2, DATA, WAIT3, or WAIT4

        The possible events are:

           PS-user         P-CONNECT.REQUEST



Rose                                                           [Page 14]

RFC 1085               ISO Presentation Services           December 1988


                           P-CONNECT.RESPONSE
                           P-RELEASE.REQUEST
                           P-RELEASE.RESPONSE
                           P-DATA.REQUEST
                           P-U-ABORT.REQUEST

           network         TCP closed or errored(*)
                           receive ConnectRequest PDU
                           receive ConnectResponse PDU
                           receive ReleaseRequest PDU
                           receive ReleaseResponse PDU
                           receive UserData(*) or CL-UserData(**) PDU
                           receive user-initiated Abort PDU
                           receive provider-initiated Abort PDU
                           timer expires(**)


        The possible actions are:

           PS-user         P-CONNECT.INDICATION
                           P-CONNECT.CONFIRMATION
                           P-RELEASE.INDICATION
                           P-RELEASE.CONFIRMATION
                           P-DATA.INDICATION
                           P-U-ABORT.INDICATION
                           P-P-ABORT.INDICATION

           network         open TCP(*)
                           close TCP(*)
                           send ConnectRequest PDU
                           send ConnectResponse PDU
                           send ReleaseRequest PDU
                           send ReleaseResponse PDU
                           send UserData(*) or CL-UserData(**) PDU
                           send user-initiated Abort PDU
                           send provider-initiated Abort PDU
                           set timer(**)

           (*)   tcp-based service only
           (**)  udp-based service only

10.1. Elements of Procedure specific to the tcp-based service

   The provider maintains the following information for each
   presentation connection:

      - a local designator for the PS-user




Rose                                                           [Page 15]

RFC 1085               ISO Presentation Services           December 1988


      - a local designator for a TCP connection

      - the state of the connection (e.g., IDLE, WAIT1, and so on)

   Upon receiving an event from the network, the provider finds the
   associated presentation connection.  Matching is done by simply
   comparing local designators for the TCP connection.  Whenever a
   connection remains in or returns to the IDLE state, any associated
   resources, such as an attachment to a local TCP port, are released.

   In the procedures which follow, outgoing PDUs are "placed on the
   input queue for the serializer".  This has a different meaning
   depending on the type of PDU being enqueued.  If the PDU is not an
   abort PDU (user-initiated or provider-initiated), then the PDU is
   simply appended to the input queue regardless of the number of PDUs
   present.  If however, the PDU is an abort PDU, then the provider
   checks the size of the input queue.  If the input queue is non-empty
   or if the serializer is busy transmitting to the network, then the
   abort PDU is discarded, and the serializer is flushed, aborting any
   output to the network in progress.  However, if the input queue is
   empty, then the Abort PDU is appended to the queue, and a small timer
   started.  If the timer expires before the PDU has been serialized and
   transmitted, then the serializer is flushed, aborting any output to
   the network in progress.

   Further, in general, whenever the TCP connection is closed (either
   locally by the provider, or remotely by the network) or has errored,
   the serializer is flushed.  The one exception to this is if a
   ReleaseResponse PDU is being serialized and transmitted to the
   network.  In this case, the provider will not close the TCP
   connection until after the serializer has finished.

10.2. Elements of Procedure specific to the udp-based service

   The provider maintains the following information for each
   presentation connection:

      - a local designator for the PS-user

      - the 32-bit IP address and 16-bit UDP port number of the
        initiating host

      - the 32-bit IP address and 16-bit UDP port number of the
        responding host

      - the session connection identifier used to establish the
        presentation connection




Rose                                                           [Page 16]

RFC 1085               ISO Presentation Services           December 1988


      - a local designator for an UDP endpoint

      - the state of the connection (e.g., IDLE, WAIT1, and so on)

      - a retransmission counter

   Upon receiving an event from the network, the provider finds the
   associated presentation connection.  Matching is done on the basis of
   addresses, ports, and the session connection identifier (i.e., two
   different presentation connections may differ only in their session
   connection identifier).  If no presentation connection can be found,
   then for the purposes of discussion, it may be assumed that a
   "vanilla" presentation connection is created and initialized to the
   IDLE state.  Further, whenever a connection remains in or returns to
   the IDLE state, any associated resources, such as an attachment to a
   local UDP port, are released.

   In the procedures which follow, outgoing PDUs are "placed on the
   input queue for the serializer".  This means that the ASN.1 object is
   serialized and the resulting sequence of octets is sent as a single
   UDP datagram.

10.3. State Transitions

   Following are the rules for transitioning states.  If an event
   associated with a user-generated primitive is omitted, then it is an
   interface error for the user to issue that primitive in the given
   state.  Each state considers all possible incoming PDUs.

   We assume that for the tcp-based service, that some entity starts a
   passive TCP open.  When the passive open completes, the entity, using
   some local rule, locates a PS-user to be associated with the incoming
   presentation connection.  This presentation connection is then placed
   in the IDLE state.  The entity then continues listening for other
   passive opens to complete.  The mechanisms associated with this
   entity are entirely a local matter, the concept of this listener is
   introduced solely as a modeling artifact.

   Finally, if the udp-based service is selected, then CL-UserData PDUs
   are exchanged by the provider instead of UserData PDUs.


                                    IDLE state

        Event:     P-CONNECT.REQUEST primitive issued

   Based on the quality of service parameter and the list of network
   addresses in the called presentation address parameter, the provider



Rose                                                           [Page 17]

RFC 1085               ISO Presentation Services           December 1988


   selects an address for the use of the presentation connection.  The
   method for making this determination is a local matter.  (Appendix C
   discusses a strategy which might be used.)  For the discussion that
   follows, we assume that a network address supporting the desired
   quality of service has been determined.

   Based on the network address chosen from the called presentation
   address parameter, the provider selects a compatible network address
   from the calling presentation address parameter.  The provider
   attaches itself to the port associated with this network address.
   (By local determination, this address need not be used, and an
   "ephemeral" port may be chosen by the provider.)

   For the tcp-based service, the provider attempts to establish a TCP
   connection to the network address listed in the called presentation
   address.  If the connection can not be established, the P-
   CONNECT.CONFIRMATION(-) primitive is issued with a reason of
   provider-rejection, and the provider remains in the IDLE state.

   Regardless, the user data parameter is placed in a ConnectRequest
   PDU, which is put on the input queue for the serializer.

   For the udp-based service, the provider sets the retransmission
   counter to a small value (e.g., 2), and now starts a small timer.

   Regardless, the provider enters the WAIT1 state.


        Event:     ConnectRequest PDU received

   The provider issues the P-CONNECT.INDICATION primitive and enters the
   WAIT2 state.


        Event:     any other PDU received

   If the PDU is not an Abort PDU, the provider constructs a provider-
   initiated Abort PDU, which is put on the input queue for the
   serializer.  Regardless, the provider remains in the IDLE state.


                                    WAIT1 state

        Event:     P-U-ABORT.REQUEST primitive issued

   The user data parameter is placed in an Abort PDU, which is put on
   the input queue for the serializer.  The provider enters the IDLE
   state.



Rose                                                           [Page 18]

RFC 1085               ISO Presentation Services           December 1988


        Event:     ConnectResponse PDU received

   For the udp-based service, the timer is cancelled.  If the PDU
   indicates rejection, the P-CONNECT.CONFIRMATION(-) primitive is
   issued and the provider enters the IDLE state.  Otherwise, the P-
   CONNECT.CONFIRMATION(+) primitive is issued and the provider enters
   the DATA state.


        Event:     user-initiated Abort PDU received

   The provider issues the P-U-ABORT.INDICATION primitive and enters the
   IDLE state.


        Event:     any other PDU received

   If the PDU not an Abort PDU, the provider constructs a provider-
   initiated Abort PDU, which is put on the input queue for the
   serializer.  Regardless, The provider issues the P-P-ABORT.INDICATION
   primitive and enters the the IDLE state.


        Event:     timer expires

   The provider decrements the retransmission counter.  If the resulting
   value is less than or equal to zero, the provider issues the P-
   CONNECT.CONFIRMATION(-) primitive and enters the IDLE state.
   Otherwise, a ConnectRequest PDU is put on the input queue for the
   serializer, the small timer is started again, and the provider
   remains in the WAIT1 state.


                                    WAIT2 state

        Event:     P-CONNECT.RESPONSE primitive issued

   The user data parameter is placed in a ConnectResponse PDU, which is
   put on the input queue for the serializer.  If the result parameter
   had the value user-rejection, the provider enters the IDLE state.
   Otherwise if the parameter had the value acceptance, the provider
   enters the DATA state.









Rose                                                           [Page 19]

RFC 1085               ISO Presentation Services           December 1988


        Event:     P-U-ABORT.REQUEST primitive issued

   The user data parameter is placed in an Abort PDU, which is put on
   the input queue for the serializer.  The provider enters the IDLE
   state.