home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / misc / volume36 / msend / part01 / Protocol < prev    next >
Encoding:
Text File  |  1993-03-22  |  7.0 KB  |  174 lines
  1.         User-To-User Message Transfer Protocol (UMTP)
  2.  
  3.                  by Jim Frost
  4.  
  5.                  May 18, 1988
  6.  
  7. INTRODUCTION
  8.  
  9. In order to facilitate a real-time user-to-user communication system
  10. between networked hosts, the User-To-User Message Transfer Protocol
  11. (UMTP) was developed.  When fully implemented, it supports manual
  12. routing, remote broadcasts, and remote terminal selection.
  13.  
  14. PROTOCOL DESCRIPTION
  15.  
  16. UMTP works on a request-reply basis.  Every request must have a reply.
  17. Requests are always send to a host, replies always come from a host.
  18.  
  19. MESSAGE REQUEST PACKETS
  20.  
  21. A message request packet is structured as follows:
  22.  
  23.   u_short taddrlen;        /* length of taddr string */
  24.   u_short tttylen;         /* length of ttty string */
  25.   u_short msglen;          /* length of msg string */
  26.   u_short fwdcount;        /* forwarding count */
  27.   u_short mode;            /* mode bits */
  28.   char    taddr[taddrlen]; /* "to" address string */
  29.   char    ttty[tttylen];   /* "to" tty string */
  30.   char    msg[msglen];     /* message string */
  31.  
  32. U_short's are unsigned short integers in network byte order.
  33.  
  34. Strings are non-null terminated ASCII.  Their lengths are determined
  35. by the length fields that preceed them.
  36.  
  37. The "taddr" field describes the user name that the packet is being
  38. sent to on the daemon's host.  Optionally a packet can be routed by
  39. appending "@host" to the user's name (eg "madd@bu-it").  Each daemon
  40. receiving a routed packet should strip the destination host out of the
  41. taddr field and send the remainder of the field.
  42.  
  43. As an example of how the taddr field should be treated at successive
  44. stops, consider the user request to deliver a message to
  45. "madd@bu-it@bucsf".  The client will strip off the "@bucsf", connect
  46. to the bucsf daemon, and transmit a packet with the taddr field set to
  47. "madd@bu-it".  Bucsf will in turn strip off the "@bu-it" and transmit
  48. a packet with the taddr field set to "madd".  Bu-it will then attempt
  49. to deliver the message to user "madd".
  50.  
  51. The taddr field cannot be longer than 1024 characters.
  52.  
  53. After making the original connection, all subsequent message packets
  54. should have the same taddr field.  Some hosts may allow different
  55. taddr fields, but it is not recommended and should be avoided.
  56.  
  57. The "ttty" field is only used when sending to a particular terminal
  58. (see the section on the mode field, which follows).  It is ignored
  59. otherwise; tttylen should be zero (indicating no ttty field).  The
  60. ttty field should contain the minimum necessary string to identify the
  61. destination terminal (eg "tty01" and "console" on BSD UNIX systems).
  62. The ttty field cannot be longer than 10 characters.
  63.  
  64. The "msg" field is used to store the message to be sent in its
  65. entirety.  The message should contain the text string that is to
  66. be written to the destination user's terminal.  The string should
  67. contain a "signature" which indicates (at a minimum) the sender's name
  68. and machine.  A good example msg field is:
  69.  
  70.   "madd@bu-it: this is an example message"
  71.  
  72. Valid ASCII characters are 7, 9, 10, and 32 through 126.  These are
  73. ^G (bell), ^I (tab), ^J (newline), and space through tilde (~).  A
  74. null string (msglen zero) indicates that the packet is to be sent to
  75. the destination daemon (including any routing) but not processed at
  76. that point.  This is usually used to request the closing of an open
  77. connection.  The msg field cannot be longer than 1024 characters.
  78.  
  79. The "mode" field gives information describing what to do with the
  80. incoming packet.
  81.  
  82.   SM_CLOSE     1 /* close connection after reply */
  83.   SM_TTY       2 /* send to tty */
  84.   SM_BROADCAST 4 /* broadcast */
  85.  
  86. If SM_CLOSE is specified, the network connection is to be closed
  87. following the reply packet; if it is not specified, the connection
  88. must remain open.
  89.  
  90. If SM_TTY is specified, the message should not be sent to a user, but
  91. instead to a particular terminal.  The ttty field must have the
  92. terminal description.  If a user name is given in the taddr field, it
  93. should be ignored.
  94.  
  95. If SM_BROADCAST is specified, a broadcast message is te be attempted
  96. on the destination host.  If a user name is given in the taddr field
  97. or a terminal name in the ttty field, it should be ignored.  If
  98. SM_BROADCAST is specified in conjunction with SM_TTY, SM_TTY is
  99. ignored.  SM_BROADCAST requests should always return a reply error
  100. number of RE_OK (message delivered) or RE_NOBROAD (broadcasting
  101. disabled).
  102.  
  103. The "fwdcount" field is used when a destination host allows users to
  104. forward messages automatically (in a way similar to the BSD UNIX
  105. .forward file).  Whenever a message is forwarded automatically (as
  106. opposed to manual routing), this field should be incremented by one.
  107. After 5 hops, RE_FWDLOOP should be returned.  This insures that
  108. automatic forwarding cannot cause an infinite loop of message
  109. forwards.  If the message is not being automatically forwarded, this
  110. field should be passed without change.
  111.  
  112. REPLY PACKETS
  113.  
  114. A reply packet is structured as follows:
  115.  
  116.   u_short errno;       /* error number */
  117.   u_short msglen;      /* length of msg field */
  118.   char    msg[msglen]; /* text string describing the error (if any) */
  119.  
  120. Valid error numbers are:
  121.  
  122.   RE_OK       0 /* message delivered ok */
  123.   RE_SYSERR   1 /* system error */
  124.   RE_NOUSER   2 /* user doesn't exist on this host */
  125.   RE_NOMSGS   3 /* user's terminal may not be written to */
  126.   RE_NOTTHERE 4 /* user is not logged on at the destination */
  127.   RE_NOROUTE  5 /* routing is denied at this host */
  128.   RE_NOBROAD  6 /* broadcasting is denied at this host */
  129.   RE_FWDLOOP  7 /* forwarding loop (too many forwards) */
  130.   RE_INTERR   8 /* something really really bad happened */
  131.  
  132. RE_OK indicates that all went well.  This is the only error that does
  133. not cause automatic termination of a connection.
  134.  
  135. RE_SYSERR indicates that some kind of system error occurred which
  136. caused delivery to fail.
  137.  
  138. RE_NOUSER indicates that the requested user does not have an account
  139. on the destination machine.
  140.  
  141. RE_NOMSGS indicates that the requested user is logged on, but is not
  142. receiving messages at any of his terminals.
  143.  
  144. RE_NOTTHERE indicates that the requested user is not logged on.
  145.  
  146. RE_NOROUTE indicates that routing is disabled at one of the daemons
  147. along the route.
  148.  
  149. RE_NOBROAD indicates that system broadcasts are not allowed at the
  150. destination host.
  151.  
  152. RE_FWDLOOP indicates that automatic message forwarding went more than
  153. 5 hops before finding the end of user message forwarding requests.
  154.  
  155. RE_INTERR indicates that the message packet caused an internal error
  156. in the daemon.
  157.  
  158. All errors returned (except RE_OK) must have a description of the
  159. error in the "msg" field.  The "msg" field may not be longer than 1024
  160. characters.
  161.  
  162. TIMEOUTS
  163.  
  164. To prevent the accumulation of dead or idle daemons on any host,
  165. connections time out after ten minutes.  No network traffic indicates
  166. a timeout -- it should be done independently at each client and
  167. daemon.  This insures a long enough time to deliver a message over
  168. long distances and through heavy traffic, but keeps idle or dead
  169. connections to a minimum.
  170.  
  171. If you want to keep a connection from idling out, send packets with a
  172. zero msglen at intervals of less than ten minutes, but be sure that no
  173. other packet is being transmitted at the same time.
  174.