Conference lassie::ucx

5520.0. "UCX Interpretation of RFC 793 (TCP) reqs" by LEXS01::SCEPPA (Nick @ OFO) Fri May 16 1997 13:51

   I have some questions regarding UCX's interpretation of the TCP spec, aka
   RFC 793. All quotes below come directly from the RFC. The page number of
   the quotes are included as footnotes.

   The first two questions stem from my goal, which is to establish a TCP
   connection between two specific processes. The last two questions are
   general clarification questions.

   1. "Two processes which issue active OPENs to each other at the same time
       will be correctly connected." [1]

       From the quote above, I infer that two processes should be able to
       establish a connection if they issue active OPENs to each other.

       I've briefly played around trying to do this with UCX (with two
       processes issuing $QIO (IO$_ACCESS) to each other, and neither process
       issuing a $QIO (IO$_ACCESS+IO$_ACCEPT)), but I haven't been successful.
       The moment the first process tries to issue a $QIO (IO$_ACCESS), I get
       the VMS error, "%MCR-F-REJECT, connect to network object rejected".

       This makes me somewhat leery of the phrase "at the same time".

       So, which of the following cases, if any, represent UCX's interpretation
       of reference [1] ? (In all cases below, assume that process P1 on host
       H1 wishes to establish a TCP connection with process P2 on host H2, and
       that both process P1 and process P2 issue active OPENs to each other).

       (a) if process P1 on host H1 issues an active OPEN, but process P2
           on host H2 hasn't even been started yet, then the TCP on host H1
           will wait (either indefinitely, or some connection timeout time)
           until process P2 on host H2 is started-up and issues an active OPEN.

       (b) if process P1 on host H1 issues an active OPEN, but process P2
           on host H2 hasn't even been started yet, then the TCP on host H1
           will return an error to process P1 indicating that we are unable to
           establish a connection with process P2 on host H2.

       (c) none of the above. If this is the case, please explain.

   2. "There are two principal cases for matching the sockets in the local
       passive OPENs and an foreign active OPENs.  In the first case, the
       local passive OPENs has fully specified the foreign socket.  In this
       case, the match must be exact." [2]

       Given that I wasn't too successful with the two active OPENs approach,
       I figured I'd try to have process P1 on host H1 issue a fully specified
       passive OPEN (i.e., a passive OPEN with a specific foreign socket), and
       then have process P2 on host H2 issue an active OPEN.

       In this case, a connection between P1 and P2 is correctly established.
       That's good. Unfortunately, if I make another test run where another
       process P3 on another host H3 issues an active OPEN to process P1 on
       host H1, the TCP on host H1 willingly establishes a connection with
       P3 on H3, which seems contradictory to the phrase in reference [2]
       that states "the match must be exact."

       Is this a "feature" of UCX, or am I misinterpreting the spec ?

   3. "Sometimes users need to be sure that all the data they have
       submitted to the TCP has been transmitted.  For this purpose a push
       function is defined." [3]

       The TCP spec further suggests that the push function should be provided
       to the caller with a PUSH parameter in SEND call.

       My guess is that UCX does not support the PUSH as part of a "SEND"
       (i.e., $QIO (IO$_WRITExBLK)), but **DOES** support the PUSH as part
       of an "OPEN" (i.e., $QIO (IO$_SETCHAR) with the TCP option, NODELAY).
       Am I correct ? If I'm incorrect, please explain.

   4. "The TCP makes use of the internet protocol type of service field and
       security option to provide precedence and security on a per connection
       basis to TCP users.  Not all TCP modules will necessarily function in
       a multilevel secure environment; some may be limited to unclassified
       use only, and others may operate at only one security level and
       compartment.  Consequently, some TCP implementations and services to
       users may be limited to a subset of the multilevel secure case." [4]

       My guess is that UCX does NOT support this feature. I am correct ?
       If I'm incorrect, how can the precedence and security of a connection
       be specified ?


Footnotes:
----------
[1]  Postel, J. (ed.), "Transmission Control Protocol - DARPA Internet Program
     Protocol Specification", RFC 793, USC/Information Sciences Institute,
     September 1981. p. 11.
[2]  Ibid, p. 11
[3]  Ibid, p.  4
[4]  Ibid, p. 13