1Received: from plato.Chemietechnik.Uni-Dortmund.DE 2 by mail.Chemietechnik.Uni-Dortmund.DE id AA20183; Mon, 7 Jun 93 09:46:43 +0200 3From: Heiko Wengler <hw@plato.Chemietechnik.Uni-Dortmund.DE> 4Message-Id: <9306070746.AA04496@plato.Chemietechnik.Uni-Dortmund.DE> 5Subject: README for SHORT_PACKETS 6To: short@plato.chemietechnik.uni-dortmund.de 7Date: Mon, 7 Jun 1993 09:46:41 +0200 (MET DST) 8X-Mailer: ELM [version 2.4 PL13] 9Content-Type: text 10Content-Length: 6423 11 12 13 Short Packets Code by Tedd Hadley and Heiko Wengler. 14 15 16 Extra feature: ',' puts up a menu ('network' for your .xtrekrc) with 17 1 toggle options and 1 integer entry field: 18 and two new keys: '-' updateSmall 'xx' (not assigned yet) updateMiddle (:-) 19 'UpdateSmall' gives you an update of all weapons+Planets+Kills. ( <400 bytes) 20 'UpdateMiddle' is updateAll without the Stats. (< 700 bytes) 21 UpdateAll (<2200 bytes) 22 orig UpdateAll (4192 bytes) 23 24 MENU: 25 26 [Don't] Receive variable and short packets (1) 27 Receive threshold: (2) 28 Done 29 30 (1) Variable and short packets. This tells the server to send several 31 new types of packets instead of the original types. The technical 32 details follow at the end. 33 34 (2) Receive threshold. This is complete experimental. If a non-zero 35 threshold is specified the server tries to not overload the 36 connection. 37 This option could be not implemented in the server. 38 You should give as a threshold the number of bytes per second 39 you wanna give from your bandwith. 40 For example if you set the threshold to 500 bytes. And you are 41 playing with 5 updates/sec. You have a threshold of 42 500/updates = 100bytes/update. The server checks after every update 43 if he wrote more than the limit. If yes the server skips your 44 next update and you get a warning from your client. 45 This can actually halve your Updates/sec. Not more. (Eg if you 46 play with 5 updates it 'slows' you down to 3 updates.) 47 Minimum limit per update is 60 bytes. (Threshold = 60 * updates then.) 48 If you set it to 0 Server ends testing. 49 ( If you wanna calculate your bandwith requirements you should count 50 the tcp/ip overhead of 64 bytes to the actual data. For example 51 if you wanna play with a 9600 Baud modem. You have a bandwith 52 of 1200 bytes. you can subtract 200 bytes for client-server 53 communication. So you have 1000 bytes to play with. With 5 updates 54 you need under tcp/ip (5*64=)320 bytes for headers. 55 You have then ~650 bytes for serverdata. That means you should 56 set the threshold to 650 bytes. ( 130 bytes per update are much. 57 All playermovement(16 players) +SP_S_YOU + 16 Torps.) I do not 58 think that you ever get 16 player packets in one update. 59 That leaves you with some more "weaponsdata" :-) 60 If you have another protocol you must compute the overhead by 61 yourself. 62 And any limit smaller than 500 bytes /update means that after 63 an UpdateAll the next update is skipped. 64 65**************************************************************************** 66 Variable and short packet justification: The three largest contributors 67 to netrek bandwidth are the packets SP_PLAYER (all player movement), 68 SP_YOU (information relating to your ship statistics, and your status) 69 and SP_TORP (torp movement). In one test I got these statistics: 70 71 SP_PLAYER: 2407 K 72 SP_YOU: 1408 K 73 SP_TORP: 1118 K 74 SP_STATS: 262 K 75 SP_FLAGS: 148 K 76 SP_WARNING: 139 K 77 SP_TORP_INFO: 90 K 78 SP_MESSAGE: 82 K, 79 ... (the remaining packets account for about 50K) 80 81 Without much doubt, the first three (SP_PLAYER, SP_YOU, SP_TORP) contribute 82 most of the overhead. So... 83 84 NEW PACKETS: 85 86 ORIGINAL SIZE (bytes) NEW SIZE (bytes) 87 -------------------------------------------------------------- 88 SP_PLAYER 12 SP_S_PLAYER 4 (**) 89 SP_YOU 32 SP_S_YOU 12 90 SP_S_YOU_SS 12 91 SP_TORP 12 SP_S_TORP ~4 (***) 92 SP_TORP_INFO 8 SP_S_TORPINFO 1 93 SP_PLANET 12 SP_S_PLANET 6 (*) 94 SP_MESSAGE 84 SP_S_MESSAGE 8-76 95 SP_WARNING 84 SP_S_WARNING 4 96 97 (*) variable packets, each packet containing 2 bytes of type & length 98 information and some number of 6-byte entries, 99 (**) variable packets, each packet containing 4 (or 12) bytes of type & length 100 information and some number of 4-byte entries, 101 (***) The torp packet is really a packet container for 9 bit pixelcoordinates. 102 Look into the code to figure out :-) 103 104 Notice that the reduction in network traffic is very close to 40-70% of 105 the original. 106 107 SP_S_PLAYER: byte bit description 108 ----------------------- 109 0 0-4 player number, 5 local or galactic, 6 = 9. x-bit, 7 9. y-bit 110 1 0-3 speed, 4-7 direction of ship 111 2 0-7 low 8 bits from X-Pixelcoordinate 112 3 0-7 low 8 bits from Y-Pixelcoordinate 113 114 SP_S_TORP: byte range 115 ----------------------- 116 0 0-7 Packettype 117 1 0-7 Bitset describing which torps are in this packet. 118 2 0-7 Torpnumber of first torp( num*8=torpnumber) 119 3 A number of 9 Bit pairs. Each describing one 120 torp. 121 ( The 9 bit numbers are the torpcoordinates in 122 pixel-coordinates.) 123 All rounded up to 4 byte boundaries. 124 125 SP_S_YOU and SP_S_YOU_SS are the result of dividing SP_YOU into two 126 packets. Most of the time, SP_YOU gets sent because ship status has 127 changed, i.e. damage, fuel, or shields. The remaining information, 128 hostile, swar, armies, and flags are not needed as often. Therefore it 129 makes sense to split SP_YOU into two packets: 130 131struct youshort_spacket { /* SP_S_YOU */ 132 char type; 133 134 char pnum; 135 char hostile; 136 char swar; 137 138 char armies; 139 char whydead; 140 char whodead; 141 142 char pad1; 143 144 unsigned flags; 145}; 146 147 and 148 149struct youss_spacket { /* SP_S_YOU_SS */ 150 char type; 151 char pad1; 152 153 unsigned short damage; 154 unsigned short shield; 155 unsigned short fuel; 156 unsigned short etemp; 157 unsigned short wtemp; 158}; 159 160The new SP_S_PLANET: All info as in the old packet but only 255 armies. 161 162struct planet_s_spacket { /* body of SP_S_PLANET */ 163 char pnum; 164 char owner; 165 char info; 166 uchar armies; /* more than 255 Armies ? ... */ 167 short flags; 168}; 169 170struct warning_s_spacket { /* SP_S_WARNING */ 171 char type; 172 uchar whichmessage; 173 char argument, argument2; /* for phaser etc ... */ 174}; 175Instead of sending the strings i send only an index into an string array. 176This works also for all weapons warnings with arguments. (like Phaser.) 177(eg: old: Phaserpacket (16) + SP_WARNING = 100 bytes. now only 20.) 178 179 Limitations: Only 64 Players can be send with SP_S_PLAYER. 180 181