home *** CD-ROM | disk | FTP | other *** search
/ Deathday Collection / dday.bin / utils / killdoom / killdoom.doc < prev    next >
Text File  |  1994-03-08  |  9KB  |  195 lines
  1. KILLDOOM V1.00A by Stephan A. Edelman
  2. NetLink Online Information Services
  3. (C) 1994. All Rights Reserved. *** FREEWARE ***
  4.  
  5. -------------------------------------------------------------------------
  6. DISCLAIMER:
  7.  
  8. EXCEPT AS RESTRICTED BY LAW, THE SOFTWARE PROGRAMS CONTAINED IN THIS
  9. ARCHIVE ARE PROVIDED "AS IS" WITHOUT ANY WARRANTY OF ANY KIND, EITHER
  10. EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, ANY IMPLIED 
  11. WARRANTIES OF MERCHANTABILITY, TITLE OR FITNESS FOR A PARTICULAR 
  12. PURPOSE. YOU MAY WITHOUT CHARGE, REPRODUCE AND DISTRIBUTE COPIES OF
  13. THIS ARCHIVE PROVIDED YOU DO NOT (1) RECEIVE ANY DIRECT PAYMENT,
  14. COMMERCIAL BENEFIT, OR OTHER CONSIDERATION FOR THE REPRODUCTION,
  15. DISTRIBUTION OR USE, OR DISTRIBUTE THIS ARCHIVE AS PART OF OR IN
  16. COMBINATION WITH ANY OTHER SOFTWARE OR HARDWARE PRODUCT WITHOUT THE
  17. PRIOR WRITTEN CONSENT OF NETLINK ONLINE INFORMATION SERVICES. 
  18. (2) CHANGE OR OMIT ANY PROPRIETARY RIGHTS NOTICE APPEARING IN THE FILES
  19. CONTAINED IN THE ARCHIVE.
  20. -------------------------------------------------------------------------
  21.  
  22. -------------------------------------------------------------------------
  23. CAUTION:
  24.  
  25. THIS UTILITY CAN PRODUCE IPX BROADCAST PACKETS AT MAXIMUM WORKSTATION 
  26. THROUGHPUT. DEPENDING ON THE NETWORK TOPOLOGY USED, THIS CAN CAUSE SEVERE 
  27. NETWORK TRAFFIC, AND, IN SOME CASES, CAUSE HEAVY NETWORK CONGESTION THAT
  28. WILL NOT ALLOW ANY USERS TO CONNECT TO THE NETWORK. WHEN USING THIS
  29. UTILITY YOU SHOULD AT LEAST SPECIFY A 10ms DELAY BETWEEN TRANSMITTED
  30. PACKETS.
  31. ---------------------------------------------------------------------------
  32.  
  33. Motivation
  34. =-=-=-=-=-
  35.  
  36. Although (NET)DOOM is an impressive programming masterpiece, that should 
  37. be praised in many respects, it does contain some rather strange network
  38. programming practices. When two or more users are running DOOM in network
  39. playing mode, each of the players sends out periodic status information
  40. about his/her current position and the objects (monsters) in its immediate
  41. environment. These update packets are broadcasted to *ALL* stations on the 
  42. network at maximum throughput (I have measured over 300 frames/sec) by 
  43. *EACH* of the stations which causes extremely slow network performance. 
  44. In an effort to eliminate the use of NETDOOM on our network, we set out 
  45. to develop a utility that would locate potential stations (or users) 
  46. running NETDOOM and terminate their game.  The ability of this utility
  47. to identify users running NETDOOM only works with versions 1.0 and 1.1
  48. of DOOM. DOOM V1.2 does *NOT* utilize broadcast packets anymore, so this
  49. utility will not be succesfull in finding users. However, it is still
  50. succesfull in terminating the game of any current version of NETDOOM.
  51.  
  52.  
  53. How it works
  54. -=-=-=-=-=-=
  55.  
  56. KILLDOOM uses two mandatory parameters, a starting socket number and
  57. an ending socket number. These specify the different "channels" that
  58. users can operate on. This allows multiple games to be running on a 
  59. single network. KILLDOOM has the following syntax:
  60.  
  61.  
  62. Usage: KILLDOOM <start socket> <end socket> [delay (ms)] [-s]
  63.        options:
  64.                 <start socket> starting network socket number (hex)
  65.                 <end socket>   ending network socket number (hex)
  66.                 [delay]        delay time between broadcasts (optional)
  67.                 [-s]           scan network first for DOOM users, then
  68.                                terminate DOOM session(s) and write to log
  69.                                file (optional)
  70.  
  71.  
  72. Each of these options will be briefly described below.
  73.  
  74. <start socket>  As indicated above, this refers to the first network
  75.                 socket number that KILLDOOM should start sending packets
  76.                 on (or listen for users when the -s option is specified).
  77.                 This number can be anywhere between 0 - 0xFFFF. Note that
  78.                 all numbers entered are specified in hexadecimal.
  79.  
  80. <end socket>    This refers to the last network socket number that KILLDOOM
  81.                 should send packets on (or listen for users when the -s
  82.                 option is specified). This number can be anywhere between
  83.                 1 - 0xFFFF. Note that this number should be in hexadecimal
  84.                 and larger than the <start socket> number.
  85.  
  86. [delay]         This argument is optional. It specifies (in decimal) the
  87.                 delay between packets that are sent out over the network.
  88.                 After broadcasting a packet on a particular socket, KILLDOOM
  89.                 will wait for [delay] milliseconds before proceeding to the
  90.                 next socket. It is recommended that you specify at least
  91.                 10ms here if you are running on an ETHERNET.
  92.  
  93. [-s]            This option scans the network socket numbers (given in
  94.                 the <start socket> and <end socket> arguments) for NETDOOM
  95.                 users. These users are reported in the KILLDOOM.LOG file
  96.                 before their game is terminated. Note that the [delay]
  97.                 option is ignored when this flag is specified.
  98.  
  99.  
  100.  
  101. Scanning for users
  102. -=-=-=-=-=-=-=-=-=
  103.  
  104. When you have specified the -s option on the command-line, KILLDOOM first
  105. scans the socket numbers specified before sending packets out on the network.
  106. It does *NOT* send any packets out if it did not find any users. This was
  107. done in order to reduce network traffic. Note that this utility will *NOT*
  108. catch users that are running NETDOOM V1.2 or later, due to the fact that
  109. id Software changed the way that NETDOOM communicates across the network.
  110. The logfile (KILLDOOM.LOG) that is written has the following form:
  111.  
  112.  
  113. 03-08-1994 22:11 10.00.5A.EA.95.B9 (DAVE) 0
  114. 03-08-1994 22:11 10.00.5A.EC.0D.F4 (STEPHAN) 0
  115. 03-08-1994 22:11 10.00.5A.EA.35.A2 (JOHN) 0
  116. 03-08-1994 22:11 10.00.5A.ED.12.33 (DENNIS) 1
  117. 03-08-1994 22:11 10.00.5A.EA.31.C0 (no name) 1
  118.  
  119. The above logfile is written after KILLDOOM has scanned the specified
  120. channels, and has found users running NETDOOM. In the above example,
  121. three users (DAVE, STEPHAN and JOHN) are playing a game with/against
  122. each other, and two other users (DENNIS and 'no name') are also playing
  123. a (separate) game together. The name enclosed in brackets refers to
  124. the Novell login name used by the user. If the user is not connected to
  125. the network (i.e., not logged in), the 'no name' will be indicated.
  126. You will also get entries indicating 'no name' if YOU are not logged in
  127. when running KILLDOOM. KILLDOOM needs access to the bindery in order to
  128. retrieve the usernames associated with the network addresses, and,
  129. therefore, you need to be logged in. You do *NOT* need to be supervisor
  130. in order to run this utility.
  131.  
  132.  
  133. Examples
  134. -=-=-=-=
  135.  
  136. KILLDOOM 1 100 1
  137.  
  138. Run KILLDOOM and send DOOM 'bad' packets to socket number 1 through socket
  139. number 100. Note that socket number 0 is ALWAYS included in every range
  140. that you specify. The last argument, '1', refers to a 1 ms delay between
  141. packets sent across the network.
  142.  
  143.  
  144. KILLDOOM 1 100 -s
  145.  
  146. Run KILLDOOM and send DOOM 'bad' packets only when users are running 
  147. NETDOOM on any of the sockets between 1 - 100 (socket number 0 is also
  148. scanned). If users are detected, log the date and time, their network
  149. address and username (if applicable) and terminate the game on that
  150. socket.
  151.  
  152.  
  153. Operating Environments
  154. -=-=-=-=-=-=-=-=-=-=-=
  155.  
  156. We have tested this utility in a Netware 3.10 and Netware 3.11 environment,
  157. as well as a Netware Lite environment. Note that a Netware Lite network
  158. does *NOT* have bindery services, and, therefore the log file will always
  159. contain the 'no name' entry for the user names associated with the network
  160. address.
  161.  
  162.  
  163. Conclusion
  164. -=-=-=-=-=
  165.  
  166. This utility was written to protect the corporate investment. The facts
  167. are that most users do not have their own network to play games on, so
  168. they end up playing DOOM in colleges, universities or businesses and 
  169. severely interfere with normal network operations. Our personal experiences
  170. are that, in some cases, network traffic was so high that users were unable 
  171. to connect to the network. We end up running around to find out if this 
  172. relates to a mechanical/electrical problem or if there is a piece of
  173. software out there 'jamming' the network. We hope that KILLDOOM will serve
  174. useful in your network environment.
  175.  
  176. If you have any questions/comments, please direct them to:
  177.  
  178.         Internet:
  179.         
  180.                 stephan.edelman@netlink.on.ca
  181.                 stephan.edelman@linet.netlink.on.ca
  182.  
  183.  
  184.         CompuServe
  185.  
  186.                 72303,1607
  187.  
  188.  
  189.  
  190. March 8, 1994
  191.  
  192.  
  193.  
  194.  
  195.