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