Netrek UDP Enhancements - Client Documentation By Andy McFadden (fadden@uts.amdahl.com) Dual channel model, version 1.0 Updated: 06-Apr-92 The client has a new menu, available by hitting '+'. It's similar to the 'O' options window, only it's not glued to the netrek window by default (so you can push it off to the side while you play). The buttons are: -------------------------------------- 0 | UDP channel is [OPEN/CLOSED] | -------------------------------------- 1 | > Status: [Connected/...] | -------------------------------------- 2 | > UDP trans dropped: X (Y% | Z%) | -------------------------------------- 3 | Sequence checking is [ON/OFF] | -------------------------------------- 4 | Sending with [simple UDP/...] | -------------------------------------- 5 | Receiving with [simple UDP/...] | -------------------------------------- 6 | Debugging info is [OFF/ON...] | -------------------------------------- 7 | Force reset to TCP | -------------------------------------- 8 | Update everything | -------------------------------------- 9 | Done | -------------------------------------- Explanations: 0 Pressing this button opens or closes the UDP channel. UDP transmissions are only possible when the channel is open. Note that it is actually possible to send & receive using only TCP while the UDP channel is open, but that would be pointless. 1 This displays the current state of the connection. Possible values: - Connected (this is the normal state) - Requesting switch to UDP - Requesting switch to TCP - Verifying UDP connection 2 This displays the total number of UDP transmissions dropped during the current game (X), that number expressed as a percentage (Y), and the number of transmissions which have been dropped recently (Z). Z% is computed once every minute; after it's displayed, the counters are reset to zero. Thus Z is an indication of recent line conditions, while Y tells you how conditions were over the entire game. 3 Clicking on this toggles sequence checking. When sequence checking is ON, packets from the server which arrive out of order are thrown away. This prevents a number of possibly nasty bugs from occurring (the least of which is watching your ship jump around when an old update arrives). When sequence checking is OFF, the "transmissions dropped" values are not updated. 4 This determines how packets are sent. There are four settings: - Send with TCP only. If your TCP link is decent but you are dropping UDP commands, this is useful. - Send with simple UDP. Most commands will be sent via UDP. This is the default. - Send with enforced UDP (state only). Several of the commands which are sent via UDP will be repeated if the next update doesn't reflect that change. For example, if you try to raise shields but they aren't up on the next update, the "raise shields" command will be resent. Note that some commands will be repeated up to 10 times. On a lagged system, this can result in every command being sent twice. - Send with enforced UDP (state+weap). This is like the previous, except that phasers and plasmas are also repeated (but only once). This will usually result in warnings about phasers not recharging or limits on computer power, which should be ignored. 5 This determines how packets are sent by the server. There are four settings: - Receive with TCP only. This tells the server to transmit everything using TCP only. This is rather silly, but what the hell. - Recieve with simple UDP. The server sends critical packets with TCP, and non-critical packets with UDP. This is the default. - Receive with fat UDP. The server adds some previously sent data onto newer packets, but only if there's room. Eventually all previously sent data will be sent again, so if you missed a planet update the first time around you'll get it eventually. - Receive with double UDP. The server sends critical packets with TCP, non-critical packets with UDP, and semi-critical packets in two consecutive UDP transmissions. The idea is that one or the other of the transmissions with semi-critical information may be lost, but probably not both. This idea may not always work; more testing is needed. It also increases the strain on the network, so it shouldn't be used if you have a reliable local connection. WARNING: this relies on the sequencing mechanism to drop the extra packets. If you turn off sequence checking, you may get weird results. NOTE: initial results have not been promising. This may be disabled in future clients/servers. 6 There are three levels of debugging info: - OFF (the default). - Connection messages only. Prints diagnostics when you connect, disconnect, or something goes wrong. If you are having problems, you should use this setting; it's silent until something goes wrong. - Verbose info. This prints a line every time something is sent or received on the UDP line (unless somebody has commented V_UDPDIAG out of defs.h on your copy of the client). This is more information than most people want or need, and it'll slow your updates down, so leave it off unless you're curious. 7 If your UDP connection gets jammed up for some reason, hit this button. It'll close the UDP socket, reset all connection-related information, and reset all the menu options to defaults. It does all this rather abruptly and could jam future UDP connection attempts, so don't use it unless you really need to (i.e., don't hit it just because your client hasn't received updates in the last five seconds). 8 If you've got ghost torps or planets you can't see info on, click here (or hit '=', the "update all" key). This will cause the server to mark its copies of much of its internal state as "never been sent." The next update will be a fairly big one... Unless the updates themselves get dropped, your display should synchronize with the server. To prevent people from loading down the server maliciously, there will be a period of a few seconds during which update requests will be ignored (it also means that, if your commands are getting dropped, you can slam '=' several times and not worry about getting a big network burst). 9 Done. Click this to close the window. If you try to switch to UDP on a server which doesn't support it, the client will eventually time out. Unless you're using the recvfrom() option in the client, the game will not hang during this period. It is generally to your advantage to NOT use enforced UDP, fat UDP, or double UDP, because they cause more information to be sent than is really necessary. This will degrade overall performance, and make your connection worse by increasing the amount of time that your client and server processes spend handling incoming packets. If you're only getting 2 or 3% packet loss, it's probably better to deal with a few ghost torps, and just hit the "update all" button if something doesn't look right (like somebody who just died still has kills, or you can't get info on a planet you're orbiting). If you get 5 or 10% packet loss, or your commands are being dropped regularly, then switching to enforced and/or fat UDP is a good idea. Messages you might encounter: "UDP connection established" Congratulations, you're in. "Switched to TCP-only connection" Congratulations, you're out. "Timed out waiting for UDP response from server" "UDP connection request timed out" Odds are this server doesn't support UDP. You'll see one or the other of these messages, depending on how your client is configured. "UDP link severed" Whoops. Something broke your UDP connection, so the client and server have reset themselves to a TCP-only connection. "Sent request for full update" This acknowledges that the update request has been sent. It could get lost. If so, send it again; the server will ignore duplicate requests for about five seconds after receiving the first, so hitting the key three or four times is considered acceptable behavior. "Request is in progress, do not disturb" Stop trying to switch. It'll happen. "Unable to establish UDP connection" "Connection attempt failed" Something in the collection of connect()s and bind()s didn't happen. These usually indicates a failure on the client machine. "UDP protocol request denied" The server admin has set "UDP=0" in his .sysdef file. UDP connections are possible, but are being rejected at the moment. "UDP protocol request failed (bad version)" Your version of the UDP protocol doesn't match what the server is using. The following are warnings generated by the server: "WARNING: BROKEN mode is enabled" You're playing on a server with a self-inflicted 20% packet loss rate. This exists to test certain protocols, like fat UDP. "Server can't do that UDP mode" This will appear if you try to change to a UDP mode that the server isn't aware of. Shouldn't happen unless you mess around with your client. "Server will send with TCP only" "Server will send with simple UDP" "Server will send with fat UDP; sent full update" "Server will send with double UDP" "Request for double UDP DENIED (set to simple)" This should be pretty obvious. If double UDP has been excised from the server, you'll get the last message instead of the second-to-last message. "Update request DENIED (chill out!)" Stop banging on the "update all" key. "Server UDP is v%.1f, client is v%.1f" If your version is off, the server will try to be helpful and tell you what the problem is. If you enable the first notch of debugging, you'll get more verbose information explaining what failed and why. It's meant to be informative, not readable; if you don't understand it, don't worry about it. Things like connection failures should be easy to diagnose from the information given (though you may need to talk to the server admin to see what's going on at the other side as well). Notes for people running through Internet gateways: Recompile the client with "-DGATEWAY" in CFLAGS in the Makefile. Then change the code at the end of "main.c" to reflect your site. The gateway program ("gw", written by Kevin Smith) with my UDP extensions should be available on John Hardwick's FTP site (gs69.sp.cs.cmu.edu, /usr/jch/netrek/); it explains most of what you need to know. You will have an extra box on the '+' menu, which shows you what it thinks the gateway machine's name is and what ports it will try to use. It ain't elegant, but hey, it works. Final bits: If you're using a UDP-capable client, there's a 99.99% chance that I did *NOT* write the client. My changes are supplied as diffs and pieces of source code, not as an entire client... If you can't get a window to open or don't like some aspect of the display or controls, don't send me mail, I have no control over it. Similarly, please don't ask me for a UDP-capable client. The source code is available on all the popular FTP sites, so just grab it from there. My client binary won't help you much, unless you're running under UTS 2.1.3 on an Amdahl mainframe.