home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / unix / volume25 / pty4 / part07 / SESS.draft2 < prev    next >
Encoding:
Text File  |  1992-02-18  |  11.0 KB  |  290 lines
  1. An introduction to session management
  2. Daniel J. Bernstein
  3. draft 2
  4. 10/4/91
  5.  
  6.  
  7. 1. Session basics
  8.  
  9.           < session, n. ... 4. any period of activity. >
  10.  
  11. When a user sits down in front of a multi-user computer, gives his login
  12. name and password, and starts typing, he's begun a _session_. Within
  13. that session he might read mail, edit files, compile and run programs,
  14. and even play games. What happens if the screen explodes?
  15.  
  16. A typical UNIX system lets a user log in through a network, or over a
  17. phone connection between the user's modem and the computer's modem. But
  18. if the phone line suddenly becomes too noisy, or the network doesn't
  19. work, the user's connection may drop. The system will then terminate the
  20. login session. Any programs run by the user will be signalled that the
  21. connection was hung up. If they ask the user for input, they won't get
  22. any. If they produce output, the output will vanish.
  23.  
  24. Other operating systems are more helpful. VMS, for instance, keeps the
  25. session running inside the computer. When the user establishes another
  26. connection and logs in again, the computer asks if he'd like to
  27. reconnect to the original session. Programs started under the session
  28. won't notice what happened. This is a primitive form of _session
  29. management_. (It is also an abuse of terminology, as the ``session''---
  30. the ``period of activity''---really consists of two periods. On the
  31. other hand, from the point of view of the programs under the session,
  32. there hasn't been any interruption.)
  33.  
  34. This paper describes a session management system which the author has
  35. developed for BSD UNIX and its variants. In section 2 we describe the
  36. three fundamental operations making up the system. In section 3 we show
  37. how the system appears to novice users. In section 4 we give several
  38. examples of more complex session management techniques which cannot be
  39. performed under VMS.
  40.  
  41.  
  42. 2. sess, disconnect, reconnect
  43.  
  44. The session management system consists of three basic operations. To
  45. illustrate the operations we use pictures:
  46.  
  47.    user ==== tty ==== csh                                         (1)
  48.  
  49. A double line, such as ====, represents a two-way flow of information.
  50. Here the user types characters, which the UNIX kernel processes inside a
  51. tty device and then sends to the user's shell, csh. What csh prints is
  52. then sent back through the tty to the user.
  53.  
  54. When csh starts a job, the picture changes:
  55.  
  56.             ---------------
  57.            /               \
  58.    user ==== tty ==== csh      who
  59.                \                |
  60.                 \              sort
  61.                  \              |
  62.                   ------------ more
  63.  
  64. Here the user has started a pipeline, who | sort | more. To simplify the
  65. illustration somewhat we pretend that all I/O from the pipeline is sent
  66. through the shell:
  67.  
  68.    user ==== tty ==== csh ---- who
  69.                          \      |
  70.                           \    sort
  71.                            \    |
  72.                             -- more
  73.  
  74. A job consisting of only one process looks like this:
  75.  
  76.    user ==== tty ==== csh ==== vi
  77.  
  78. If the user's connection dies, the tty effectively disappears:
  79.  
  80.               csh ==== vi
  81.  
  82. Without a place to send input and output, csh and vi receive the HUP
  83. signal and die a messy death.
  84.  
  85. The first session management operation is sess. When the user, starting
  86. from picture (1), types ``sess ksh'', he creates a session:
  87.  
  88.                    /------\      +------+
  89.    user ==== tty ==== csh ==== | conn | ==== | sess | === ksh
  90.                    \------/      +------+
  91.  
  92. The session consists of the square box, called the _master_ because it's
  93. in charge of session management, with ksh running below it. The session
  94. is connected to the rounded box, also called the _signaller_ because it
  95. signals csh when the session is finished. Normally both boxes are
  96. completely transparent, and the user can start jobs under the session:
  97.  
  98.                    /------\      +------+
  99.    user ==== tty ==== csh ==== | conn | ==== | sess | === ksh ==== vi     (2)
  100.                    \------/      +------+
  101.  
  102. (In fact, from ksh's point of view, the sess box looks just like a tty.
  103. It is actually a _pseudo-tty_, also known as a _pseudo-terminal_.
  104. Further discussion of pseudo-terminals is beyond the scope of this
  105. paper.)
  106.  
  107. What happens if the user's connection drops? As before, the original tty
  108. disappears, and csh sputters and dies. The signaller disappears too:
  109.  
  110.                                  +------+
  111.                                              | sess | === ksh ==== vi
  112.                                  +------+
  113.  
  114. However, the session keeps running. sess doesn't mind being
  115. disconnected. It waits for a reconnect, as described below. Meanwhile,
  116. ksh doesn't have the slightest inkling that the connection is gone.
  117.  
  118. The user can in fact force a disconnect manually. This is the second
  119. fundamental operation. Starting from picture (2), if the user types
  120. ``disconnect'' to ksh, the connection will be severed:
  121.  
  122.    user ==== tty ==== csh
  123.  
  124.                              +------+
  125.                                              | sess | === ksh ==== vi     (3)
  126.                              +------+
  127.  
  128. The signaller exits quietly, and the user can now type commands to csh.
  129.  
  130. How does the user reconnect to a disconnected session? He uses the third
  131. fundamental operation, the reconnect command. The system assigns each
  132. session a name. If the user starts a new session, it might look like
  133. this:
  134.  
  135.                    /------\      +------+
  136.    user ==== tty ==== csh ==== | conn | ==== | sess | === qsh
  137.                    \------/      +--p7--+
  138.  
  139. Here ``p7'' is this session's name. Say the disconnected session was
  140. named ``qb'':
  141.  
  142.                    /------\      +------+
  143.    user ==== tty ==== csh ==== | conn | ==== | sess | === qsh
  144.                    \------/      +--p7--+
  145.  
  146.                              +------+
  147.                                              | sess | === ksh ==== vi
  148.                              +--qb--+
  149.  
  150. If the user types ``reconnect qb'' to qsh, nothing happens immediately,
  151. but the signaller remembers his reconnect:
  152.  
  153.                    /------\      +------+
  154.    user ==== tty ==== csh ==== | conn | ==== | sess | === qsh
  155.                    \-+qb+-/      +--p7--+
  156.  
  157.                              +------+
  158.                                              | sess | === ksh ==== vi
  159.                              +--qb--+
  160.  
  161. As soon as session p7 exits (or is disconnected), the reconnect takes
  162. effect:
  163.  
  164.                    /------\      +------+
  165.    user ==== tty ==== csh ==== | conn | ==== | sess | === ksh ==== vi
  166.                    \------/      +--qb--+
  167.  
  168. Now it's just as if session qb had been connected all along. The user
  169. can type commands to vi. If the connection disappears again, he can
  170. reconnect again, any number of times.
  171.  
  172. Why doesn't reconnect take effect immediately? There are several
  173. reasons. Perhaps the most important is that before reconnecting the user
  174. may want to terminate the currently connected session---or he may want
  175. to disconnect it, so that he can reconnect to it later. This reconnect
  176. interface doesn't force one choice or the other. The user may also want
  177. to perform some lengthy operations before reconnecting, and it's easier
  178. to schedule the reconnect once and do it at his leisure than to have to
  179. worry about the reconnect after all the operations. Finally, it is very
  180. simple to simulate an immediate reconnect using the above operations, as
  181. detailed in section 4.
  182.  
  183.  
  184. 3. Session management for users
  185.  
  186. Most users will never have to learn anything about the sess, disconnect,
  187. or reconnect commands. If a connection dies, its owner will be shown a
  188. message like this when he logs in again:
  189.  
  190.   You have a disconnected session on /dev/ttyra, with these processes:
  191.   USER       PID %CPU %MEM   SZ  RSS TT STAT START  TIME COMMAND
  192.   shmoe    17790  0.0  0.9  176  504 ra T    12:47   0:01 vi paper.3
  193.   shmoe    17331  0.0  0.7   72  384 ra I    12:31   0:00 -bin/csh (csh)
  194.   shmoe    17330  0.0  0.5  104  264 ra S    12:31   0:00 pty -ds argv0 /bin/csh
  195.   Would you like to reconnect to that session?
  196.   If so, type its two-character extension, ra.
  197.   To instead start a new session as usual, just press return:
  198.  
  199. The user will recognize the ``paper.3'' he was editing, type ra, and be
  200. reconnected to his session. The program which handles this is called
  201. ``sessmenu''. While perhaps not as friendly as the reconnect facilities
  202. under some operating systems, sessmenu isolates even novices from the
  203. trauma of losing important work.
  204.  
  205. All sessions also keep track of a long name assigned by the user. The
  206. ``sessname'' command displays or sets the current session name:
  207.  
  208.    csh% sessname
  209.    session p7
  210.    csh% sessname 'writing net test program'
  211.    csh% sessname
  212.    session p7: writing net test program
  213.    csh%
  214.  
  215. The user can see all his sessions with ``sesslist'':
  216.  
  217.    csh% sesslist
  218.    session p7 pid 16614 slave 16615 connected: writing net test program
  219.    session ra pid 8045 slave 8046 disconnected: finishing up paper.3
  220.    csh%
  221.  
  222. Two other useful commands are ``sesswho'', to show all sessions on the
  223. system and their owners, and ``sesswhere'', to show where those sessions
  224. are currently connected to. (The system administrator may disable these
  225. commands for security reasons.)
  226.  
  227.  
  228. 4. Advanced session management techniques
  229.  
  230. By combining the sess, disconnect, and reconnect commands in simple
  231. ways, a user can perform surprisingly powerful session operations. In
  232. this section we give some such combinations. The reader may enjoy
  233. drawing pictures to see how the commands work.
  234.  
  235. A user can reconnect to a disconnected session without finishing the
  236. current session with ``sess reconnect xx''. Another method for doing an
  237. immediate reconnect is ``reconnect xx; disconnect''. The second method
  238. is symmetric: if the original session was yy, the user can flip back and
  239. forth with
  240.  
  241.    csh-yy% reconnect xx; disconnect
  242.    ...
  243.    ksh-xx% reconnect yy; disconnect
  244.    ...
  245.    csh-yy% reconnect xx; disconnect
  246.  
  247. and so on. To immediately reconnect to another session and finish the
  248. current session, he can use ``reconnect xx; exit'' or ``exec reconnect xx''.
  249.  
  250. Say a user is in the middle of something---running a crucial
  251. computation, perhaps, or ``talk''ing to another user---and decides to
  252. record what's happening. With sess, reconnect, and disconnect, he can do
  253. this without starting the program again:
  254.  
  255.    [talk session going on, user types ^Z]
  256.    Stopped
  257.    csh% sess sh
  258.    $ sessname; disconnect
  259.    session rf
  260.    csh% reconnect rf; disconnect
  261.    reconnect: will connect to session rf when session p8 is done
  262.    pty: info: reconnecting to rf
  263.    pty: info: successfully connected to rf
  264.    $ sess reconnect p8 | tee talk-record
  265.    reconnect: will connect to session p8 when session q0 is done
  266.    pty: info: reconnecting to p8
  267.    pty: info: successfully connected to p8
  268.    csh% fg
  269.    [talk session continues as before]
  270.  
  271. Now everything in session p8 is recorded in talk-record. The recording
  272. is completely transparent and does not require that ``talk'' be
  273. terminated or restarted.
  274.  
  275.  
  276. 5. Where to find it
  277.  
  278. The session management system described here is freely available as part
  279. of the pty 4.0 package. pty 4.0 works on BSD-derived UNIX systems.
  280.  
  281. The author's session management model is based on Bellovin's ``Session
  282. Tty'' Manager [1], which is not as powerful as pty but is better
  283. integrated into the login system.
  284.  
  285.  
  286. References
  287.  
  288. [1] Bellovin, S. M.  The ``Session Tty'' Manager. In USENIX Conference
  289. Proceedings, San Francisco, Summer 1988, 339-354.
  290.