rfc681.txt

RFC 的详细文档！

NWG/RFC# 681                                  JBP 14-MAY-75 14:38  32157
3/18/75     NETWORK UNIX                                     S. Holmgren



                            NETWORK UNIX                               1

                         RFC 681 NIC 32157                             2

INTRODUCTION                                                           3

   THE  UNIX  TIME-SHARING  SYSTEM  [1] PRESENTS SEVERAL INTERESTING
   CAPABILITIES AS AN ARPA NETWORK MINI-HOST.   IT  OFFERS POWERFUL
   LOCAL  PROCESSING FACILITIES IN TERMS OF USER PROGRAMS, SEVERAL
   COMPILERS, AN EDITOR BASED ON QED, A  VERSATILE  DOCUMENT
   PREPARATION  SYSTEM,  AND  AN EFFICIENT FILE SYSTEM FEATURING
   SOPHISTICATED ACCESS CONTROL, MOUNTABLE AND DE-MOUNTABLE
   VOLUMES, AND A UNIFIED TREATMENT OF PERIPHERALS AS SPECIAL FILES.  3a

   THE NETWORK CONTROL PROGRAM (NCP), IS  INTEGRATED  WITHIN THE
   UNIX FILE SYSTEM.  NETWORK CONNECTIONS ARE TREATED AS SPECIAL
   FILES WHICH CAN BE ACCESSED THROUGH STANDARD UNIX I/O CALLS; VIZ.
   READ,  WRITE,  OPEN, CLOSE.  SPECIAL FILES HAVE DIRECTORY ENTRIES
   SIMILAR TO NORMAL FILES EXCEPT THAT CERTAIN FLAG  BITS  ARE  SET.
   THESE FLAG BITS CAUSE SYSTEM I/O ROUTINES TO TAKE SPECIAL ACTION.
   IN UNIX, SPECIAL FILES SIGNIFY PERIPHERAL DEVICES.  FOR  EXAMPLE,
   I/O  TRANSACTION  WITH  MAGTAPE ZERO WOULD BE ACCOMPLISHED BY
   ACCESSING THE SPECIAL FILE, "/DEV/MT0".  FOR THE UNIX NETWORK
   SYSTEM,  ADDITIONAL  SPECIAL FILES WERE CREATED EACH OF WHICH
   SPECIFIES A HOST ON THE  ARPA  NETWORK.  FOR  EXAMPLE
   "/DEV/NET/HARV" REPRESENTS  THE PDP-10 AT HARVARD.  THIS SIMPLE
   ACCESS MECHANISM, THROUGH THE FILING SYSTEM, ALLOWS STANDARD ARPA
   PROTOCOLS SUCH AS TELNET  AND  FTP  TO  BE  IMPLEMENTED AS
   SWAPPABLE USER PROGRAMS, RESIDENT ONLY WHEN NEEDED.  FURTHERMORE,
   A USER MAY WRITE HIS OWN PROGRAMS TO COMMUNICATE WITH THESE
   SPECIAL FILES JUST AS THE TELNET PROGRAM DOES.  THE SAMPLE
   PROGRAM  FOUND BELOW  DEPICTS  THE ESSENTIALS OF NETWORKING FROM
   UNIX.                                                              3b

STANDARD I/O                                                           4

   TO  PRESENT  THE  BASIC PROPERTIES OF UNIX I/O, THE READ, WRITE,
   OPEN, AND CLOSE FUNCTION CALLS ARE SUMMARIZED BELOW.  EACH CALL
   MAY RESULT IN AN ERROR CODE OF MINUS ONE.                          4a

   TO MANIPULATE AN EXISTING FILE WITH READS OR  WRITES,  IT MUST
   FIRST BE OPENED WITH THE FOLLOWING CALL:                           4b
NWG/RFC# 681                                  JBP 14-MAY-75 14:38  32157
3/18/75     NETWORK UNIX                                     S. Holmgren



      FILEDES = OPEN( "ANYFILENAME",FLAG )                           4b1

   WHERE  "ANYFILENAME" IS THE ARBITRARY NAME OF THE FILE TO BE
   OPENED.  THE SECOND PARAMETER INDICATES WHETHER THE FILE IS TO BE
   READ,  WRITTEN, OR UPDATED.  THE RETURNED VALUE "FILEDES", IS
   CALLED A FILE DESCRIPTOR. IT IS AN INTEGER USED TO  IDENTIFY  THE
   FILE IN SUBSEQUENT CALLS TO READ AND WRITE.                        4c

   ONCE A FILE HAS BEEN OPENED, THE FOLLOWING CALLS  MAY  BE USED:    4d

      NBYTES = READ( FILEDES,BUFFER,COUNT );
      NBYTES = WRITE( FILEDES,BUFFER,COUNT );                        4d1

   COUNT IS THE NUMBER OF BYTES TO  BE  TRANSMITTED  BETWEEN THE
   FILE REPRESENTED BY 'FILEDES' AND THE BYTE ARRAY REPRESENTED BY
   'BUFFER'.  NBYTES IS THE NUMBER ACTUALLY TRANSMITTED.  FOR THE
   READ  CALL,  'NBYTES' MAY BE ZERO TO INDICATE THE END OF FILE; IN
   EITHER CASE, MINUS ONE WILL BE RETURNED IF THERE WAS AN ERROR.     4e

   FOR EACH OPEN FILE, THE SYSTEM MAINTAINS A POINTER TO THE NEXT
   BYTE TO BE READ OR WRITTEN.  IF N BYTES ARE TRANSMITTED, THE
   POINTER  ADVANCES  N  BYTES.   DATA WRITTEN TO A FILE AFFECT ONLY
   THOSE BYTES IN THE FILE WHICH ARE INDICATED BY  THE  POSITION  OF
   THE  WRITE  POINTER  AND  THE COUNT; NO OTHER PART OF THE FILE IS
   CHANGED.  IF THE SYSTEM POINTER INDICATES THAT  ANY  BYTES  BEING
   WRITTEN  WOULD  LIE  BEYOND  THE END OF THE FILE, THE FILE IS
   ENLARGED AS NEEDED.                                                4f

   ONCE  THE  USER HAS FINISHED PROCESSING A FILE, IT SHOULD BE
   CLOSED.  THIS IS AFFECTED WITH THE FOLLOWING CALL:                 4g

      CLOSE( FILEDES );                                              4g1

   ALTHOUGH IT IS NOT ABSOLUTELY NECESSARY TO DO A  SPECIFIC CLOSE
   ON A FILE WHEN FINISHED, (THE SYSTEM CLOSES ALL FILES WHEN A
   PROGRAM EXITS), IT IS A GOOD PRACTICE, SINCE THE  USER  IS
   ALLOWED ONLY SIXTEEN OPEN FILES.                                   4h

   THERE ARE SEVERAL ADDITIONAL SYSTEM CALLS RELATED TO  I/O WHICH
   WILL NOT BE DISCUSSED IN DETAIL.  A FEW OF THE MORE NOTABLE ONES
   ALLOW THE USER TO: GET THE STATUS OF A FILE, CHANGE THE
   PROTECTION  OR OWNERSHIP OF A FILE, CREATE A FILE, CREATE A
   DIRECTORY, MAKE A LINK TO AN EXISTING FILE,  AND  DELETE  A

NWG/RFC# 681                                  JBP 14-MAY-75 14:38  32157
3/18/75     NETWORK UNIX                                     S. Holmgren



   FILE.   FOR FURTHER INFORMATION CONCERNING THE DIFFERENT I/O
   CALLS THE READER IS DIRECTED TO THE UNIX PROGRAMMER'S MANUAL,
   FIFTH  EDITION,  K. THOMPSON, AND D. M. RITCHIE, JUNE 1974.        4i

   THE USER COMMUNICATES WITH THE  NETWORK  VIA  THESE  SAME SYSTEM
   CALLS.   FOR EXAMPLE, IF ONE WISHED TO CONNECT TO THE THE PDP-10
   AT HARVARD, THE FOLLOWING SEQUENCE OF CALLS MIGHT BE USED.         4j

      FILEDES = OPEN( "/DEV/NET/HARV",2 );
      IF( FILEDES < 0 )
         PRINTF(" HARVARD IS DEAD");
      ELSE
         WHILE( (NBYTES=READ(FILEDES,BUF,80)) > 0 )
            WRITE( 0,BUF,NBYTES );                                   4j1

   THE OPEN INSTRUCTS THE SYSTEM TO OPEN A TELNET CONNECTION TO
   HARVARD, IF MINUS ONE IS RETURNED, THE PROGRAM PRINTS A MESSAGE
   AND EXITS,  OTHERWISE THE PROGRAM WILL READ ANY BYTES SENT BY
   HARVARD AND PRINT THEM OUT ON THE CONTROLLING TELETYPE. THIS WILL
   GO  ON UNTIL  HARVARD  CLOSES THE CONNECTION (READ WILL RETURN
   MINUS ONE WHEN THE CONNECTION IS CLOSED).                          4k

UNIX TELNET                                                            5

   IN ORDER TO COMMUNICATE WITH REMOTE  HOSTS  ON  THE  ARPA
   NETWORK,  ONE  FIRST  LOGS IN TO UNIX AS A NORMAL USER.  THE USER
   THEN RUNS A PROGRAM, TELNET, WHICH AFTER ANNOUNCING ITSELF LEAVES
   HIM WITH SEVERAL OPTIONS.                                          5a

   HE MAY CONTINUE WITH HIS  NORMAL  UNIX  ACTIVITIES.  WHEN TELNET
   SEES  A  UNIX  COMMAND, IT WILL INITIATE THE REQUEST AS A
   PARALLEL TASK, IN THE SAME MANNER AS THE UNIX  COMMAND  PROCESSOR
   (THE SHELL).  SINCE THIS MAY BE DONE REGARDLESS OF WHETHER OR NOT
   A NETWORK CONNECTION IS OPEN, THE USER MAY SIMULTANEOUSLY RECEIVE
   OUTPUT  FROM A FOREIGN HOST'S SERVER TELNET AND CONVERSE WITH THE
   LOCAL UNIX SYSTEM.                                                 5b

   WHEN  THE  TELNET-USER OPENS A CONNECTION, TELNET ACCEPTS THE
   HOST NAME AND ANY SPECIAL PARAMETERS, AND DOES AN OPEN ON THE
   SPECIAL  FILE  CORRESPONDING  TO  THAT HOST.  WHEN CONTROL IS
   RETURNED, THE CONNECTION IS OPEN.   ANY FURTHER DATA RECEIVED
   FROM THE  TERMINAL NOT CONTAINING ESCAPE CHARACTER IS SENT TO THE






                                   1

NWG/RFC# 681                                  JBP 14-MAY-75 14:38  32157
3/18/75     NETWORK UNIX                                     S. Holmgren



   NETWORK FILE.   ANY DATA RECEIVED IN RESPONSE TO A READ ON THE
   NETWORK FILE, IS WRITTEN ON THE USER'S TYPEWRITER.                 5c

   COMMUNICATION CONTINUES WITH  THE  HOST  UNTIL  THE  USER WISHES
   TO CLOSE THE CONNECTION.  THE USER SIMPLY MAKES THIS KNOWN TO
   TELNET VIA A COMMAND, AND TELNET DOES A STANDARD CLOSE ON  THE
   NETWORK  FILE.  THE NEGOTIATION OF CLOSING THE NETWORK CONNECTION
   IS LEFT TO THE SYSTEM, FREEING THE USER FOR  OTHER  COMPUTATIONAL
   WORK.                                                              5d

   THERE IS SOME CHARACTER TRANSLATION AND INVISIBLE CONTROL
   INFORMATION  PASSED  BACK  AND FORTH BETWEEN THE FOREIGN HOST AND
   THE TELNET PROCESS. THIS INVOLVES RECOGNITION OF TELNET IACS  AND
   THE  TRANSLATION OF CARRIAGE RETURN(CR) AND LINE FEED(LF) TO LINE
   FEED ON ALL DATA RECEIVED  FROM  THE  NETWORK,  AND  THE  INVERSE
   TRANSLATION OF LF TO CR LF ON ALL DATA SENT TO THE NETWORK.        5e

NCP STRUCTURE                                                          6

   DUE  TO THE STRUCTURE OF BOTH THE IMP TO HOST[2] AND HOST TO
   HOST[3] NETWORK PROTOCOLS, DATA COMES FROM  THE  NETWORK
   DESTINED  NOT  ONLY  FOR  ONE  OF MANY ACTIVE PROCESSES, BUT FOR
   THE INFORMATION OF THE LOCAL HOST AS A WHOLE.  FOR  EXAMPLE,
   NETWORK TRAFFIC  SUCH  AS  A  HOST TO HOST RESET, WHICH GENERALLY
   SIGNALS THAT A FOREIGN HOST HAS COME "ALIVE" MUST BE ACKNOWLEDGED
   TO  LET THAT HOST KNOW THAT THE LOCAL HOST ITSELF IS "ALIVE".
   THEREFORE, THE LOCAL HOST MUST MONITOR DATA COMING FROM THE NET
   TO  PERFORM NOT  ONLY A MESSAGE SWITCHING FUNCTION, WHICH IS THE
   BULK OF NETWORK TRAFFIC, BUT TO PROVIDE A CONTROL AND STATUS
   FUNCTION.                                                          6a

   FURTHER,  WHEN  A  PERSON  ASSOCIATED WITH THE LOCAL HOST WISHES
   TO CARRY ON A CONVERSATION WITH A NETWORK SERVER, THE INITIAL
   CONNECTION  PROTOCOL[4]  MUST  BE USED TO PROVIDE A LOGICAL PORT
   AT EACH SITE FOR SUCCEEDING INFORMATION FLOW.                      6b

   EXPERIENCE  WITH  THE  ANTS MARK I[5] AND ANTS MARK II[6] SYSTEMS
   HAS SHOWN THAT THE ABOVE CLASSES OF  NETWORK  EVENTS  ARE
   RELATIVELY  INFREQUENT, AND THAT MOST NETWORK TRAFFIC IS IN TERMS
   OF USER DATA FLOW AND THE ASSOCIATED FLOW CONTROL( HOST  TO  HOST
   ALLOCATES  AND  IMP TO HOST RFNMS).  IT IS ALSO THE CASE THAT THE
   SOFTWARE REQUIRED TO IMPLEMENT THE STATUS AND CONTROL FUNCTION IS
   THE BULKIEST PART OF AN NCP.                                       6c





                                   2

NWG/RFC# 681                                  JBP 14-MAY-75 14:38  32157
3/18/75     NETWORK UNIX                                     S. Holmgren



   IN UNIX, THE KERNEL OF  THE  OPERATING  SYSTEM  IS  CORERESIDENT
   AND  NON-SWAPPABLE.   A LARGE KERNEL REDUCES THE MEMORY AVAILABLE