home *** CD-ROM | disk | FTP | other *** search
/ minnie.tuhs.org / unixen.tar / unixen / PDP-11 / Trees / V7 / usr / doc / uucp / network < prev   
Encoding:
Text File  |  1979-01-10  |  21.2 KB  |  729 lines

  1. .RP
  2. .if n .ls 2
  3. .ds RH Nowitz
  4. .ND "August 18, 1978"
  5. .TL
  6. A Dial-Up Network of
  7. UNIX\s6\uTM\d\s0
  8. Systems
  9. .AU
  10. D. A. Nowitz
  11. .AU
  12. M. E. Lesk
  13. .AI
  14. .MH
  15. .AB
  16. .if n .ls 2
  17. A network of over eighty
  18. .UX
  19. computer systems has been established using the
  20. telephone system as its primary communication medium.
  21. The network was designed to meet the growing demands for
  22. software distribution and exchange.
  23. Some advantages of our design are:
  24. .IP -
  25. The startup cost is low.
  26. A system needs only a dial-up port,
  27. but systems with automatic calling units have much more
  28. flexibility.
  29. .IP -
  30. No operating system changes are required to install or use the system.
  31. .IP -
  32. The communication is basically over dial-up lines,
  33. however, hardwired communication lines can be used
  34. to increase speed.
  35. .IP -
  36. The command for sending/receiving files is simple to use.
  37. .sp
  38. Keywords: networks, communications, software distribution, software maintenance
  39. .AE
  40. .NH 
  41. Purpose
  42. .PP
  43. The widespread use of the
  44. .UX
  45. system
  46. .[
  47. ritchie thompson bstj 1978
  48. .]
  49. within Bell Laboratories
  50. has produced problems of software distribution and maintenance.
  51. A conventional mechanism was set up to distribute the operating
  52. system and associated programs from a central site to the
  53. various users.
  54. However this mechanism alone does not meet all software
  55. distribution needs.
  56. Remote sites generate much software and must transmit it to
  57. other sites.
  58. Some
  59. .UX
  60. systems
  61. are themselves central sites for redistribution
  62. of a particular specialized utility,
  63. such as the Switching Control Center System.
  64. Other sites have particular, often long-distance needs for
  65. software exchange; switching research,
  66. for example, is carried on in
  67. New Jersey, Illinois, Ohio, and Colorado.
  68. In addition, general purpose utility programs are written at
  69. all
  70. .UX
  71. system sites.
  72. The
  73. .UX
  74. system is modified
  75. and enhanced by many people in many places and
  76. it would be very constricting to deliver new software in a one-way
  77. stream without any alternative
  78. for the user sites to respond with changes of their own.
  79. .PP
  80. Straightforward software distribution is only part of the problem.
  81. A large project may exceed the capacity of a single computer and
  82. several machines may be used by the one group of people.
  83. It then becomes necessary
  84. for them to pass messages, data and other information back an forth
  85. between computers.
  86. .PP
  87. Several groups with similar problems, both inside and outside of
  88. Bell Laboratories, have constructed networks built of
  89. hardwired connections only.
  90. .[
  91. dolotta mashey 1978 bstj
  92. .]
  93. .[
  94. network unix system chesson
  95. .]
  96. Our network, however, uses both dial-up and hardwired
  97. connections so that service can be provided to as many sites as possible.
  98. .NH
  99. Design Goals
  100. .PP
  101. Although some of our machines are connected directly, others
  102. can only communicate over low-speed dial-up lines.
  103. Since the dial-up lines are often unavailable
  104. and file transfers may take considerable time,
  105. we spool all work and transmit in the background.
  106. We also had to adapt to a community of systems which are independently
  107. operated and resistant to suggestions that they should all
  108. buy particular hardware or install particular operating system
  109. modifications.
  110. Therefore, we make minimal demands on the local sites
  111. in the network.
  112. Our implementation requires no operating system changes;
  113. in fact, the transfer programs look like any other user
  114. entering the system through the normal dial-up login ports,
  115. and obeying all local protection rules.
  116. .PP
  117. We distinguish ``active'' and ``passive'' systems
  118. on the network.
  119. Active systems have an automatic calling unit
  120. or a hardwired line to another system,
  121. and can initiate a connection.
  122. Passive systems do not have the hardware
  123. to initiate a connection.
  124. However, an
  125. active system can be assigned the job of calling passive
  126. systems and executing work found there;
  127. this makes a passive system the functional equivalent of
  128. an active system, except for an additional delay while it waits to be polled.
  129. Also, people frequently log into active systems and
  130. request copying from one passive system to another.
  131. This requires two telephone calls, but even so, it is faster
  132. than mailing tapes.
  133. .PP
  134. Where convenient, we use hardwired communication lines.
  135. These permit much faster transmission and multiplexing
  136. of
  137. the communications link.
  138. Dial-up connections are made at either 300 or 1200 baud;
  139. hardwired connections are asynchronous up to 9600 baud 
  140. and might run even faster on special-purpose communications
  141. hardware.
  142. .[
  143. fraser spider 1974 ieee
  144. .]
  145. .[
  146. fraser channel network datamation 1975
  147. .]
  148. Thus, systems typically join our network first as
  149. passive systems and when
  150. they find the service more important, they acquire
  151. automatic calling units and become active
  152. systems; eventually, they may install high-speed
  153. links to particular machines with which they
  154. handle a great deal of traffic.
  155. At no point, however, must users change their
  156. programs or procedures.
  157. .PP
  158. The basic operation of the network is very simple.
  159. Each participating system has a spool directory,
  160. in which work to be done (files to be moved, or commands to be executed
  161. remotely) is stored.
  162. A standard program,
  163. .I uucico ,
  164. performs all transfers.
  165. This program starts by identifying a particular communication channel
  166. to a remote system with which it will hold a conversation.
  167. .I Uucico
  168. then selects a device and establishes the connection,
  169. logs onto the remote machine
  170. and starts the
  171. .I uucico
  172. program on the remote machine.
  173. Once two of these programs are connected, they first agree on a line protocol,
  174. and then start exchanging work.
  175. Each program in turn, beginning with the calling (active system) program,
  176. transmits everything it needs, and then asks the other what it wants done.
  177. Eventually neither has any more work, and both exit.
  178. .PP
  179. In this way, all services are available from all sites; passive sites,
  180. however, must wait until called.
  181. A variety of protocols may be used; this conforms to the real,
  182. non-standard world.
  183. As long as the caller and called programs have a protocol in common,
  184. they can communicate.
  185. Furthermore, each caller knows the hours when each destination system
  186. should be called.
  187. If a destination is unavailable, the data intended for it
  188. remain in the spool directory until the destination machine can be reached.
  189. .PP
  190. The implementation of this
  191. Bell Laboratories network
  192. between independent sites, all of which
  193. store proprietary programs and data,
  194. illustratives the pervasive need for security
  195. and administrative controls over file access.
  196. Each site, in configuring its programs and system files,
  197. limits and monitors transmission.
  198. In order to access a file a user needs access permission
  199. for the machine that contains the file and access permission
  200. for the file itself.
  201. This is achieved by first requiring the user to use his password
  202. to log into his local machine and then his local
  203. machine logs into the remote machine whose files are to be accessed.
  204. In addition, records are kept identifying all files
  205. that are moved into and out of the local system,
  206. and how the requestor of such accesses identified
  207. himself.
  208. Some sites may arrange
  209. to permit users only
  210. to call up
  211. and request work to be done;
  212. the calling users are then called back
  213. before the work is actually done.
  214. It is then possible to verify
  215. that the request is legitimate from the standpoint of the
  216. target system, as well as the originating system.
  217. Furthermore, because of the call-back,
  218. no site can masquerade as another
  219. even if it knows all the necessary passwords.
  220. .PP
  221. Each machine can optionally maintain a sequence count for
  222. conversations with other machines and require a verification of the
  223. count at the start of each conversation.
  224. Thus, even if call back is not in use, a successful masquerade requires
  225. the calling party to present the correct sequence number.
  226. A would-be impersonator must not just steal the correct phone number,
  227. user name, and password, but also the sequence count, and must call in
  228. sufficiently promptly to precede the next legitimate request from either side.
  229. Even a successful masquerade will be detected on the next correct
  230. conversation.
  231. .NH
  232. Processing
  233. .PP
  234. The user has two commands which set up communications,
  235. .I uucp
  236. to set up file copying,
  237. and
  238. .I uux
  239. to set up command execution where some of the required
  240. resources (system and/or files)
  241. are not on the local machine.
  242. Each of these commands will put work and data files
  243. into the spool directory for execution by
  244. .I uucp
  245. daemons.
  246. Figure 1 shows the major blocks of the file transfer process.
  247. .SH
  248. File Copy
  249. .PP
  250. The
  251. .I uucico
  252. program is used to perform all communications between
  253. the two systems.
  254. It performs the following functions:
  255. .RS
  256. .IP - 3
  257. Scan the spool directory for work.
  258. .IP -
  259. Place a call to a remote system.
  260. .IP -\ \ 
  261. Negotiate a line protocol to be used.
  262. .IP -\ \ 
  263. Start program
  264. .I uucico
  265. on the remote system.
  266. .IP -\ \ 
  267. Execute all requests from both systems.
  268. .IP -\ \ 
  269. Log work requests and work completions.
  270. .RE
  271. .LP
  272. .I Uucico
  273. may be started in several ways;
  274. .RS
  275. .IP a) 5
  276. by a system daemon,
  277. .IP b)
  278. by one of the
  279. .I uucp
  280. or
  281. .I uux
  282. programs,
  283. .IP c)
  284. by a remote system.
  285. .RE
  286. .SH
  287. Scan For Work
  288. .PP
  289. The file names in the spool directory are constructed to allow the
  290. daemon programs
  291. .I "(uucico, uuxqt)"
  292. to determine the files they should look at,
  293. the remote machines they should call
  294. and the order in which the files for a particular
  295. remote machine should be processed.
  296. .SH
  297. Call Remote System
  298. .PP
  299. The call is made using information from several
  300. files which reside in the uucp program directory.
  301. At the start of the call process, a lock is
  302. set on the system being called so that another
  303. call will not be attempted at the same time.
  304. .PP
  305. The system name is found in a
  306. ``systems''
  307. file.
  308. The information contained for each system is:
  309. .IP
  310. .RS
  311. .IP [1]
  312. system name,
  313. .IP [2]
  314. times to call the system
  315. (days-of-week and times-of-day),
  316. .IP [3]
  317. device or device type to be used for call,
  318. .IP [4]
  319. line speed,
  320. .IP [5]
  321. phone number,
  322. .IP [6]
  323. login information (multiple fields).
  324. .RE
  325. .PP
  326. The time field is checked against the present time to see
  327. if the call should be made.
  328. The
  329. .I
  330. phone number
  331. .R
  332. may contain abbreviations (e.g. ``nyc'', ``boston'') which get translated into dial
  333. sequences using a
  334. ``dial-codes'' file.
  335. This permits the same ``phone number'' to be stored at every site, despite
  336. local variations in telephone services and dialing conventions.
  337. .PP
  338. A ``devices''
  339. file is scanned using fields [3] and [4] from the
  340. ``systems''
  341. file to find an available device for the connection.
  342. The program will try all devices which satisfy
  343. [3] and [4] until a connection is made, or no more
  344. devices can be tried.
  345. If a non-multiplexable device is successfully opened, a lock file
  346. is created so that another copy of
  347. .I uucico
  348. will not try to use it.
  349. If the connection is complete, the
  350. .I
  351. login information
  352. .R
  353. is used to log into the remote system.
  354. Then
  355. a command is sent to the remote system
  356. to start the
  357. .I uucico
  358. program.
  359. The conversation between the two
  360. .I uucico
  361. programs begins with a handshake started by the called,
  362. .I SLAVE ,
  363. system.
  364. The
  365. .I SLAVE
  366. sends a message to let the
  367. .I MASTER
  368. know it is ready to receive the system
  369. identification and conversation sequence number.
  370. The response from the
  371. .I MASTER
  372. is
  373. verified by the
  374. .I SLAVE
  375. and if acceptable, protocol selection begins.
  376. .SH
  377. Line Protocol Selection
  378. .PP
  379. The remote system sends a message
  380. .IP "" 12
  381. P\fIproto-list\fR
  382. .LP
  383. where
  384. .I proto-list
  385. is a string of characters, each
  386. representing a line protocol.
  387. The calling program checks the proto-list
  388. for a letter corresponding to an available line
  389. protocol and returns a
  390. .I use-protocol
  391. message.
  392. The
  393. .I use-protocol
  394. message is
  395. .IP "" 12
  396. U\fIcode\fR
  397. .LP
  398. where code is either a one character
  399. protocol letter or a
  400. .I N
  401. which means there is no common protocol.
  402. .PP
  403. Greg Chesson designed and implemented the standard
  404. line protocol used by the uucp transmission program.
  405. Other protocols may be added by individual installations.
  406. .SH
  407. Work Processing
  408. .PP
  409. During processing, one program is the
  410. .I MASTER
  411. and the other is
  412. .I SLAVE .
  413. Initially, the calling program is the
  414. .I MASTER.
  415. These roles may switch one or more times during
  416. the conversation.
  417. .PP
  418. There are four messages used during the
  419. work processing, each specified by the first
  420. character of the message.
  421. They are
  422. .KS
  423. .TS
  424. center;
  425. c l.
  426. S    send a file,
  427. R    receive a file,
  428. C    copy complete,
  429. H    hangup.
  430. .TE
  431. .KE
  432. .LP
  433. The
  434. .I MASTER
  435. will send
  436. .I R
  437. or
  438. .I S
  439. messages until all work from the spool directory is
  440. complete, at which point an
  441. .I H
  442. message will be sent.
  443. The
  444. .I SLAVE
  445. will reply with
  446. \fISY\fR, \fISN\fR, \fIRY\fR, \fIRN\fR, \fIHY\fR, \fIHN\fR,
  447. corresponding to
  448. .I yes
  449. or
  450. .I no
  451. for each request.
  452. .PP
  453. The send and receive replies are
  454. based on permission to access the
  455. requested file/directory.
  456. After each file is copied into the spool directory
  457. of the receiving system,
  458. a copy-complete message is sent by the receiver of the file.
  459. The message
  460. .I CY
  461. will be sent if the
  462. .UX
  463. .I cp
  464. command, used to copy from the spool directory, is successful.
  465. Otherwise, a
  466. .I CN
  467. message is sent.
  468. The requests and results are logged on both systems,
  469. and, if requested, mail is sent to the user reporting completion
  470. (or the user can request status information from the log program at any time).
  471. .PP
  472. The hangup response is determined by the
  473. .I SLAVE
  474. program by a work scan of the spool directory.
  475. If work for the remote system exists in the
  476. .I SLAVE's
  477. spool directory, a
  478. .I HN
  479. message is sent and the programs switch roles.
  480. If no work exists, an
  481. .I HY
  482. response is sent.
  483. .PP
  484. A sample conversation is shown in Figure 2.
  485. .SH
  486. Conversation Termination
  487. .PP
  488. When a
  489. .I HY
  490. message is received by the
  491. .I MASTER
  492. it is echoed back to the
  493. .I SLAVE
  494. and the protocols are turned off.
  495. Each program sends a final "OO" message to the
  496. other.
  497. .NH
  498. Present Uses
  499. .PP
  500. One application of this software is remote mail.
  501. Normally, a
  502. .UX
  503. system user
  504. writes ``mail dan'' to send mail to
  505. user ``dan''.
  506. By writing ``mail usg!dan''
  507. the mail is sent to user 
  508. ``dan''
  509. on system ``usg''.
  510. .PP
  511. The primary uses of our network to date have been in software maintenance.
  512. Relatively few of the bytes passed between systems are intended for
  513. people to read.
  514. Instead, new programs (or new versions of programs)
  515. are sent to users, and potential bugs are returned to authors.
  516. Aaron Cohen has implemented a
  517. ``stockroom'' which allows remote users to call in and request software.
  518. He keeps a ``stock list'' of available programs, and new bug
  519. fixes and utilities are added regularly.
  520. In this way, users can always obtain the latest version of anything
  521. without bothering the authors of the programs.
  522. Although the stock list is maintained on a particular system,
  523. the items in the stockroom may be warehoused in many places;
  524. typically each program is distributed from the home site of
  525. its author.
  526. Where necessary, uucp does remote-to-remote copies.
  527. .PP
  528. We also routinely retrieve test cases from other systems
  529. to determine whether errors on remote systems are caused
  530. by local misconfigurations or old versions of software,
  531. or whether they are bugs that must be fixed at the home site.
  532. This helps identify errors rapidly.
  533. For one set of test programs maintained by us,
  534. over 70% of the bugs reported from remote sites
  535. were due to old software, and were fixed
  536. merely by distributing the current version.
  537. .PP
  538. Another application of the network for software maintenance
  539. is to compare files on two different machines.
  540. A very useful utility on one machine has been
  541. Doug McIlroy's ``diff'' program
  542. which compares two text files and indicates the differences,
  543. line by line, between them.
  544. .[
  545. hunt mcilroy file
  546. .]
  547. Only lines which are
  548. not identical are printed.
  549. Similarly,
  550. the program ``uudiff''
  551. compares files (or directories) on two machines.
  552. One of these directories may be on a passive system.
  553. The
  554. ``uudiff'' program
  555. is set up to work similarly to the inter-system mail, but it is slightly
  556. more complicated.
  557. .PP
  558. To avoid moving large numbers of usually identical
  559. files,  
  560. .I uudiff
  561. computes file checksums
  562. on each side, and only moves files that are different
  563. for detailed comparison.
  564. For large files, this process can be iterated; checksums can be computed
  565. for each line, and only those lines that are different
  566. actually moved.
  567. .PP
  568. The ``uux'' command has
  569. been useful for providing remote output.
  570. There are some machines which do not have hard-copy
  571. devices, but which are connected over 9600 baud
  572. communication lines to machines with printers.
  573. The
  574. .I uux
  575. command allows the formatting of the
  576. printout on the local machine and printing on the
  577. remote machine using standard
  578. .UX
  579. command programs.
  580. .br
  581. .NH
  582. Performance
  583. .PP
  584. Throughput, of course, is primarily dependent on transmission speed.
  585. The table below shows the real throughput of characters
  586. on communication links of different speeds.
  587. These numbers represent actual data transferred;
  588. they do not include bytes used by the line protocol for
  589. data validation such as checksums and messages.
  590. At the higher speeds, contention for the processors on both
  591. ends prevents the network from driving the line full speed.
  592. The range of speeds represents the difference between light and
  593. heavy loads on the two systems.
  594. If desired, operating system modifications can
  595. be installed
  596. that permit full use of even very fast links.
  597. .KS
  598. .TS
  599. center;
  600. c c
  601. n n.
  602. Nominal speed    Characters/sec.
  603. 300 baud    27
  604. 1200 baud    100-110
  605. 9600 baud    200-850
  606. .TE
  607. .KE
  608. In addition to the transfer time, there is some overhead
  609. for making the connection and logging in ranging from
  610. 15 seconds to 1 minute.
  611. Even at 300 baud, however, a typical 5,000 byte source program
  612. can be transferred in
  613. four minutes instead of the 2 days that might be required
  614. to mail a tape.
  615. .PP
  616. Traffic between systems is variable.  Between two
  617. closely related systems,
  618. we observed
  619. 20 files moved and 5 remote commands executed in a typical day.
  620. A more normal traffic out of a single system would be around
  621. a dozen files per day.
  622. .PP
  623. The total number of sites at present
  624. in the main network is
  625. 82, which includes most of the Bell Laboratories
  626. full-size machines
  627. which run the
  628. .UX
  629. operating system.
  630. Geographically, the machines range from Andover, Massachusetts to
  631. Denver, Colorado.
  632. .PP
  633. Uucp has also
  634. been used to set up another network
  635. which connects a group of
  636. systems in operational sites with the home site.
  637. The two networks touch at one
  638. Bell Labs computer.
  639. .NH
  640. Further Goals
  641. .PP
  642. Eventually, we would like to develop a full system of remote software
  643. maintenance.
  644. Conventional maintenance (a support group which mails tapes)
  645. has many well-known disadvantages.
  646. .[
  647. brooks mythical man month 1975
  648. .]
  649. There are distribution errors and delays, resulting in old software
  650. running at remote sites and old bugs continually reappearing.
  651. These difficulties are aggravated when
  652. there are 100 different small systems, instead of a few large ones.
  653. .PP
  654. The availability of file transfer on a network of compatible operating
  655. systems
  656. makes it possible just to send programs directly to the end user who wants them.
  657. This avoids the bottleneck of negotiation and packaging in the central support
  658. group.
  659. The ``stockroom'' serves this function for new utilities
  660. and fixes to old utilities.
  661. However, it is still likely that distributions will not be sent
  662. and installed as often as needed.
  663. Users are justifiably suspicious of the ``latest version'' that has just
  664. arrived; all too often it features the ``latest bug.''
  665. What is needed is to address both problems simultaneously:
  666. .IP 1.
  667. Send distributions whenever programs change.
  668. .IP 2.
  669. Have sufficient quality control so that users will install them.
  670. .LP
  671. To do this, we recommend systematic regression testing both on the
  672. distributing and receiving systems.
  673. Acceptance testing on the receiving systems can be automated and
  674. permits the local system to ensure that its essential work can continue
  675. despite the constant installation of changes sent from elsewhere.
  676. The work of writing the test sequences should be recovered in lower
  677. counseling and distribution costs.
  678. .PP
  679. Some slow-speed network services are also being implemented.
  680. We now have inter-system ``mail'' and ``diff,''
  681. plus the many implied commands represented by ``uux.''
  682. However, we still need inter-system ``write'' (real-time inter-user
  683. communication) and ``who'' (list of people logged in
  684. on different systems).
  685. A slow-speed network of this sort may be very useful
  686. for speeding up counseling and education, even
  687. if not fast enough for the distributed data base
  688. applications that attract many users to networks.
  689. Effective use of remote execution over slow-speed lines, however,
  690. must await the general installation of multiplexable channels so
  691. that long file transfers do not lock out short inquiries.
  692. .NH
  693. Lessons
  694. .PP
  695. The following is a summary of the lessons we learned in
  696. building these programs.
  697. .IP 1.
  698. By starting your network in a way that requires no hardware or major operating system
  699. changes, you can get going quickly.
  700. .IP 2.
  701. Support will follow use.
  702. Since the network existed and was being used, system maintainers
  703. were easily persuaded to help keep it operating, including purchasing
  704. additional hardware to speed traffic.
  705. .IP 3.
  706. Make the network commands look like local commands.
  707. Our users have a resistance to learning anything new:
  708. all the inter-system commands look very similar to
  709. standard
  710. .UX
  711. system
  712. commands so that little training cost
  713. is involved.
  714. .IP 4.
  715. An initial error was not coordinating enough
  716. with existing communications projects: thus, the first
  717. version of this network was restricted to dial-up, since
  718. it did not support the various hardware links between systems.
  719. This has been fixed in the current system.
  720. .SH
  721. Acknowledgements
  722. .PP
  723. We thank G. L. Chesson for his design and implementation
  724. of the packet driver and protocol, and A. S. Cohen, J. Lions,
  725. and P. F. Long for their suggestions and assistance.
  726. .[
  727. $LIST$
  728. .]
  729.