home *** CD-ROM | disk | FTP | other *** search
/ Amiga Special: Spiele Hits / Hits-CD.iso / aminet / spiele / ammud1_1.lha / AmigaMUD / Doc / Agents.txt next >
Text File  |  1997-07-14  |  43KB  |  904 lines
  1. AmigaMUD, Copyright 1997 by Chris Gray
  2.  
  3.  
  4.             The AmigaMUD Agents
  5.  
  6. The "Agents" in the AmigaMUD system are separate programs that run on
  7. the server machine, and which serve as intermediaries between the
  8. MUDServ server itself and whatever communications protocol is being
  9. used. On earlier releases of the system, only the "MUDAgent" program
  10. was used for this purpose - it handles a single serial port, doing
  11. reliable asynchronous transfers to the remote client, and converting
  12. messages between the serial format and the AmigaOS "Exec" messages
  13. used by the server. Now that AmigaMUD works over the internet, there
  14. are two more agent programs. MUDText is used to handle a text-only
  15. connection from a telnet or non-specific MUD client. MUDBinary is used
  16. to handle full connections with a remote custom client, speaking via
  17. TCP/IP messages. These two new clients are now more likely to be used
  18. than the old serial port client. They are simpler and will be
  19. described first. Note that neither MUDText nor MUDBinary can be
  20. started from the Workbench - they must be started by the "inetd"
  21. server program, or by something similar.
  22.  
  23. I personally have tested the AmigaMUD system using AmiTCP/IP. One user
  24. has had success using Miami, both with him running the MUD client to
  25. connect to my server, and with me running here to connect to his
  26. server. Any TCP/IP stack that provides the bsdsocket.library interface
  27. should work just as well. The details of setup will of course vary
  28. from stack to stack.
  29.  
  30.  
  31. Setup for TCP/IP Operation
  32.  
  33. There are two ends of the AmigaMUD system. The client end involves the
  34. "MUD" custom client. The documentation file "MUD.txt" contains
  35. information on how to use it with a TCP/IP connection to talk to a MUD
  36. server over the internet. Setting up an AmigaMUD server to be
  37. available over the internet is discussed here. A certain level of
  38. familiarity with the internet is assumed.
  39.  
  40. In order to host an AmigaMUD system over the internet you will of
  41. course need an internet connection. This typically involves being at a
  42. site that is "on" the internet, or perhaps going through a commercial
  43. ISP (Internet Service Provider) that allows the needed activities.
  44. Since the AmigaMUD system currently runs only on Amiga computers, an
  45. Amiga with internet access is needed. Best for this purpose is a
  46. fairly fast Amiga with an ethernet card, plugged into a network that
  47. is linked to the internet. An Amiga with a SLIP or PPP connection
  48. through a modem will also work, but that restricts the network
  49. capacity available, and requires a dedicated telephone line if it is
  50. to be available continuously. Those lucky people with ISDN lines to
  51. their systems are perhaps the best off. Cable modems are more
  52. difficult to use as servers like this, since they often do not have
  53. fixed IP addresses, and the cable companies sometimes explicitly
  54. disallow users from running servers.
  55.  
  56. After the hardware is setup, you will also need software to provide a
  57. "TCP/IP stack", which is the collection of drivers and protocol
  58. software that understands the internet standards in order to properly
  59. be a host on the internet. AmigaMUD does not come equipped with this
  60. software - you must obtain it elsewhere. As mentioned above, AmigaMUD
  61. is known to work with the AmiTCP/IP and Miami stacks, and should work
  62. with any stack that provides the "bsdsocket.library" interface. Note
  63. that you may not get an actual "bsdsocket.library" file to put into
  64. your "libs:" directory. AmiTCP/IP, for example, creates the library
  65. dynamically when it is started up. Because of this, the various
  66. AmigaMUD programs, when directed to use TCP/IP connections, may fail
  67. if your TCP/IP stack is not already running.
  68.  
  69. In order for one computer to contact another over a TCP/IP connection,
  70. it must know a port number to attempt the connection on. These port
  71. numbers are not related to the named AmigaOS Exec message ports that
  72. the AmigaMUD server itself uses for communication. There are usually
  73. two choices for the protocol to use for such ports - TCP or UDP.
  74. AmigaMUD only works with the reliable TCP protocol. The port numbers I
  75. have randomly chosen to use as the defaults are 6666 for a text
  76. connection, and 6667 for a binary connection with the custom AmigaMUD
  77. "MUD" client. Some sites may not allow these ports through their
  78. security firewalls, in which case others can be chosen.
  79.  
  80. With AmiTCP/IP, you must define the ports you want to use in the file
  81. "amitcp:db/services". Lines in that file look like this:
  82.  
  83. mudtext     6666/tcp
  84. mudbinary    6667/tcp
  85.  
  86. On UNIX systems, this file is usually located in the "/etc" directory.
  87.  
  88. Once you have the port numbers chosen, you need to set up something
  89. that will run the MUDText or MUDBinary agents when an external
  90. connection comes in for one of those ports. On UNIX systems and with
  91. AmiTCP/IP, this is done via the "inetd" program. This program is
  92. thought of as a "super server" which accepts connections on any of the
  93. ports it is told about, and which will then run the appropriate
  94. program for that port. This information is given to it in the file
  95. "inetd.conf", which is also located in "amitcp:db" or "/etc". Assuming
  96. you have set up the normal "AmigaMUD:" assign on your Amiga, and have
  97. created the above entries in your "services" file, the lines for
  98. AmiTCP/IP's inetd look like this:
  99.  
  100. mudtext   stream tcp nowait bin/stack=10000 AmigaMUD:Progs/MUDText MUDText
  101. mudbinary stream tcp nowait bin AmigaMUD:Progs/MUDBinary MUDBinary
  102.  
  103. If you need to add command line flags to either program, you do that
  104. by adding them at the end of the lines. For details on the format of
  105. the above lines, consult the appropriate AmiTCP/IP documentation.
  106.  
  107. With Miami, all of the above configuration is done within the main
  108. Miami program, and is set up using GUIs. Consult the Miami
  109. documentation for details. (I haven't seen it myself, so cannot help
  110. you with it, but I've been told that it *is* there, so don't bug
  111. Holger about it! In email he indicates that the appropriate entries
  112. are in the "Services" and "InetD" pages.) For other TCP/IP stacks, you
  113. will have to consult the documentation for those stacks.
  114.  
  115. With the above setup, a summary of what is going on goes something
  116. like this (for a full binary "MUD" connection):
  117.  
  118.     - server machine establishes internet connection and starts its
  119.     AmigaMUD server, and its inetd.
  120.  
  121.     ...
  122.  
  123.     - client machine establishes internet connection
  124.  
  125.     ...
  126.  
  127.     - user runs "MUD" client program, specifying (see "MUD.txt") the
  128.     name or address of the machine to connect to, along with the
  129.     TCP port to connect on.
  130.  
  131.     - inetd on server machine notices incoming connection request, and
  132.     consults its configuration to see what to do with it. If all
  133.     is well, it starts the "MUDBinary" program, and passes the
  134.     connection off to that program. Inetd will then go back to
  135.     waiting for more connection requests.
  136.  
  137.     - MUDBinary attempts to contact a MUDServ via the AmigaOS Exec
  138.     message port "MUD port" or any other name specified (see
  139.     below).
  140.  
  141.     - MUDServ and the remote MUD client begin exchanging messages to
  142.     allow character login/creation and gameplay.
  143.  
  144.     ...
  145.  
  146.     - player chooses to stop playing, and enters appropriate game
  147.     command or otherwise informs "MUD" that he/she wants to quit.
  148.     After a few messages back and forth, "MUD" will terminate on
  149.     the client machine, and the specific "MUDBinary" will
  150.     terminate on the server machine.
  151.  
  152.  
  153. MUDBinary
  154.  
  155. The MUDBinary program is used to connect a remote "MUD" client program
  156. running over TCP/IP with the server on the local machine. There will
  157. be one copy of MUDBinary running for each such client. Do not attempt
  158. to run MUDBinary manually or from the Workbench - it is designed to
  159. only be run from an "inetd" program or similar server setup. MUDBinary
  160. accepts the following command line parameters:
  161.  
  162.     -T - run using the test port "MUD test port" instead of the
  163.     default port "MUD port". This is handy if you want to run a
  164.     test server as well as a regular server.
  165.  
  166.     -P<name> - run using the given port name instead of the default
  167.     port name.
  168.  
  169.     -R<count> - use <count> as the number of server request messages
  170.     to allow to accumulate in this program. The default is 10.
  171.  
  172. There is little that can be said about M