home *** CD-ROM | disk | FTP | other *** search
- KILLDOOM V1.00A by Stephan A. Edelman
- NetLink Online Information Services
- (C) 1994. All Rights Reserved. *** FREEWARE ***
-
- -------------------------------------------------------------------------
- DISCLAIMER:
-
- EXCEPT AS RESTRICTED BY LAW, THE SOFTWARE PROGRAMS CONTAINED IN THIS
- ARCHIVE ARE PROVIDED "AS IS" WITHOUT ANY WARRANTY OF ANY KIND, EITHER
- EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY, TITLE OR FITNESS FOR A PARTICULAR
- PURPOSE. YOU MAY WITHOUT CHARGE, REPRODUCE AND DISTRIBUTE COPIES OF
- THIS ARCHIVE PROVIDED YOU DO NOT (1) RECEIVE ANY DIRECT PAYMENT,
- COMMERCIAL BENEFIT, OR OTHER CONSIDERATION FOR THE REPRODUCTION,
- DISTRIBUTION OR USE, OR DISTRIBUTE THIS ARCHIVE AS PART OF OR IN
- COMBINATION WITH ANY OTHER SOFTWARE OR HARDWARE PRODUCT WITHOUT THE
- PRIOR WRITTEN CONSENT OF NETLINK ONLINE INFORMATION SERVICES.
- (2) CHANGE OR OMIT ANY PROPRIETARY RIGHTS NOTICE APPEARING IN THE FILES
- CONTAINED IN THE ARCHIVE.
- -------------------------------------------------------------------------
-
- -------------------------------------------------------------------------
- CAUTION:
-
- THIS UTILITY CAN PRODUCE IPX BROADCAST PACKETS AT MAXIMUM WORKSTATION
- THROUGHPUT. DEPENDING ON THE NETWORK TOPOLOGY USED, THIS CAN CAUSE SEVERE
- NETWORK TRAFFIC, AND, IN SOME CASES, CAUSE HEAVY NETWORK CONGESTION THAT
- WILL NOT ALLOW ANY USERS TO CONNECT TO THE NETWORK. WHEN USING THIS
- UTILITY YOU SHOULD AT LEAST SPECIFY A 10ms DELAY BETWEEN TRANSMITTED
- PACKETS.
- ---------------------------------------------------------------------------
-
- Motivation
- =-=-=-=-=-
-
- Although (NET)DOOM is an impressive programming masterpiece, that should
- be praised in many respects, it does contain some rather strange network
- programming practices. When two or more users are running DOOM in network
- playing mode, each of the players sends out periodic status information
- about his/her current position and the objects (monsters) in its immediate
- environment. These update packets are broadcasted to *ALL* stations on the
- network at maximum throughput (I have measured over 300 frames/sec) by
- *EACH* of the stations which causes extremely slow network performance.
- In an effort to eliminate the use of NETDOOM on our network, we set out
- to develop a utility that would locate potential stations (or users)
- running NETDOOM and terminate their game. The ability of this utility
- to identify users running NETDOOM only works with versions 1.0 and 1.1
- of DOOM. DOOM V1.2 does *NOT* utilize broadcast packets anymore, so this
- utility will not be succesfull in finding users. However, it is still
- succesfull in terminating the game of any current version of NETDOOM.
-
-
- How it works
- -=-=-=-=-=-=
-
- KILLDOOM uses two mandatory parameters, a starting socket number and
- an ending socket number. These specify the different "channels" that
- users can operate on. This allows multiple games to be running on a
- single network. KILLDOOM has the following syntax:
-
-
- Usage: KILLDOOM <start socket> <end socket> [delay (ms)] [-s]
- options:
- <start socket> starting network socket number (hex)
- <end socket> ending network socket number (hex)
- [delay] delay time between broadcasts (optional)
- [-s] scan network first for DOOM users, then
- terminate DOOM session(s) and write to log
- file (optional)
-
-
- Each of these options will be briefly described below.
-
- <start socket> As indicated above, this refers to the first network
- socket number that KILLDOOM should start sending packets
- on (or listen for users when the -s option is specified).
- This number can be anywhere between 0 - 0xFFFF. Note that
- all numbers entered are specified in hexadecimal.
-
- <end socket> This refers to the last network socket number that KILLDOOM
- should send packets on (or listen for users when the -s
- option is specified). This number can be anywhere between
- 1 - 0xFFFF. Note that this number should be in hexadecimal
- and larger than the <start socket> number.
-
- [delay] This argument is optional. It specifies (in decimal) the
- delay between packets that are sent out over the network.
- After broadcasting a packet on a particular socket, KILLDOOM
- will wait for [delay] milliseconds before proceeding to the
- next socket. It is recommended that you specify at least
- 10ms here if you are running on an ETHERNET.
-
- [-s] This option scans the network socket numbers (given in
- the <start socket> and <end socket> arguments) for NETDOOM
- users. These users are reported in the KILLDOOM.LOG file
- before their game is terminated. Note that the [delay]
- option is ignored when this flag is specified.
-
-
-
- Scanning for users
- -=-=-=-=-=-=-=-=-=
-
- When you have specified the -s option on the command-line, KILLDOOM first
- scans the socket numbers specified before sending packets out on the network.
- It does *NOT* send any packets out if it did not find any users. This was
- done in order to reduce network traffic. Note that this utility will *NOT*
- catch users that are running NETDOOM V1.2 or later, due to the fact that
- id Software changed the way that NETDOOM communicates across the network.
- The logfile (KILLDOOM.LOG) that is written has the following form:
-
-
- 03-08-1994 22:11 10.00.5A.EA.95.B9 (DAVE) 0
- 03-08-1994 22:11 10.00.5A.EC.0D.F4 (STEPHAN) 0
- 03-08-1994 22:11 10.00.5A.EA.35.A2 (JOHN) 0
- 03-08-1994 22:11 10.00.5A.ED.12.33 (DENNIS) 1
- 03-08-1994 22:11 10.00.5A.EA.31.C0 (no name) 1
-
- The above logfile is written after KILLDOOM has scanned the specified
- channels, and has found users running NETDOOM. In the above example,
- three users (DAVE, STEPHAN and JOHN) are playing a game with/against
- each other, and two other users (DENNIS and 'no name') are also playing
- a (separate) game together. The name enclosed in brackets refers to
- the Novell login name used by the user. If the user is not connected to
- the network (i.e., not logged in), the 'no name' will be indicated.
- You will also get entries indicating 'no name' if YOU are not logged in
- when running KILLDOOM. KILLDOOM needs access to the bindery in order to
- retrieve the usernames associated with the network addresses, and,
- therefore, you need to be logged in. You do *NOT* need to be supervisor
- in order to run this utility.
-
-
- Examples
- -=-=-=-=
-
- KILLDOOM 1 100 1
-
- Run KILLDOOM and send DOOM 'bad' packets to socket number 1 through socket
- number 100. Note that socket number 0 is ALWAYS included in every range
- that you specify. The last argument, '1', refers to a 1 ms delay between
- packets sent across the network.
-
-
- KILLDOOM 1 100 -s
-
- Run KILLDOOM and send DOOM 'bad' packets only when users are running
- NETDOOM on any of the sockets between 1 - 100 (socket number 0 is also
- scanned). If users are detected, log the date and time, their network
- address and username (if applicable) and terminate the game on that
- socket.
-
-
- Operating Environments
- -=-=-=-=-=-=-=-=-=-=-=
-
- We have tested this utility in a Netware 3.10 and Netware 3.11 environment,
- as well as a Netware Lite environment. Note that a Netware Lite network
- does *NOT* have bindery services, and, therefore the log file will always
- contain the 'no name' entry for the user names associated with the network
- address.
-
-
- Conclusion
- -=-=-=-=-=
-
- This utility was written to protect the corporate investment. The facts
- are that most users do not have their own network to play games on, so
- they end up playing DOOM in colleges, universities or businesses and
- severely interfere with normal network operations. Our personal experiences
- are that, in some cases, network traffic was so high that users were unable
- to connect to the network. We end up running around to find out if this
- relates to a mechanical/electrical problem or if there is a piece of
- software out there 'jamming' the network. We hope that KILLDOOM will serve
- useful in your network environment.
-
- If you have any questions/comments, please direct them to:
-
- Internet:
-
- stephan.edelman@netlink.on.ca
- stephan.edelman@linet.netlink.on.ca
-
-
- CompuServe
-
- 72303,1607
-
-
-
- March 8, 1994
-
-
-
-
-