From 188ad89f8ca50c920e6578a05bd8e00d8db6894e Mon Sep 17 00:00:00 2001 From: Matthew Mondor Date: Mon, 30 Jun 2014 18:46:19 +0000 Subject: [PATCH] Update README --- mmsoftware/mystic_ships/README | 203 ++--------------------------------------- 1 file changed, 8 insertions(+), 195 deletions(-) diff --git a/mmsoftware/mystic_ships/README b/mmsoftware/mystic_ships/README index 3e29175..a83e5ec 100644 --- a/mmsoftware/mystic_ships/README +++ b/mmsoftware/mystic_ships/README @@ -1,63 +1,25 @@ -$Id: README,v 1.2 2014/06/25 12:53:13 mmondor Exp $ +$Id: README,v 1.3 2014/06/30 18:46:19 mmondor Exp $ -Note that some of this text is outdated. TODO ==== SERVER -- Add support for multiframe objects. For instance, detonations could have - multiple frames, as well as the cloaking effect. These should possibly more - be time-dependent than actual frame dependent however, considering that - frames can be delayed and their rate changed. - If there was a fixed client-side FPS for those, this would also mean that - all other objects obtained from the server would need to be recorded as - well... Possibly that if we did that it might also be possible to transmit - less frames over the network but with thrust/angle information for the client - to be able to evaluate smooth transitions between them... -- Cause older torpedoes to automatically get detonated whenever a new - torpido is fired and the maximum number of torpedoes has been reached. - Implement authentication credentials checking, limit same user to one connection only - Limit connections per ip address in number and frequency -- Implement and test using openssl with aes. Verify if the overhead +- Implement and test using OpenSSL. Verify if the overhead is negligeable enough to be worth keeping. -- Add proper connection/disconnection/events logging CLIENT -- Continue test: draw objects as they are received by the server until the - end of frame packet, at which time we would update the display flipping the - double buffered pages. This also means that we must find a way to not take - all CPU time while waiting for both SDL events and server packets ones at - the same time! Since receiving is prioritary, perhaps that we could wait - for messages from the server using a ring, since SDL events would - automatically be queued meanwhile? - Also now send user events to the server. +- Perhaps use some OpenGL NOTES ===== -An attempt to develop a portable game client using SDL among unix -and windows operating systems. The only officially supported -compiler should be GCC (and mingw under windows, avoiding the need -for cygwin libraries). The compiling/development environment when -under windows will use cygwin to provide a shell, vim and cvs, -while compile options will be specified as needed for it to use -the mingw compiler (which also comes as part of cygwin). - -Initial tests will be using SDL, SDL_mixer and SDL_net. - -If all works well, it should also be easy to use OpenGL portably. -I was already able to get portable SDL/OpenGL code working, a while -ago, but this generated no sound and had no network requirements. -Hence this test. - -Moreover, the test server under kqueue/ needed a client for further -testing to be possible at its development stage. - Since SDL_net does not provide non-blocking I/O (and it remains unclear if windows supports this properly), a decision was made to port to SDL an inter-thread messaging library I had done for use @@ -78,80 +40,8 @@ main loop. Ogg-vorbis is used for music, using SDL_mixer. Ship rotations are performed using SDL_gfx rotozoom. -It is very important to avoid having to link this client statically -against GPL or LGPL libraries, because of the viral nature of those -licenses. I do not intend to release my code under those licenses. -If it ever publically is released, it shall be done under a MIT/BSD -derived license. - -I am also thinking about dedicating a thread for the connect state -to the server, or possibly to have the writer or reader thread also -perform that task. - -It is possible that a thread be ideal for rendering as well. It -could be notified when a screen refresh is wanted, when it could -set a flag. When it's time for it to draw a frame (honoring FPS), -it would if the flag is set, or perhaps it simply could when it -wants. I wonder if it would be appropriate for the display thread -to not need a mutex, since it would always be read-only accessing -the data. - -Anticipated design so far: - Main thread - User events thread - Network receive thread - Network Send/Connect thread - Display thread (the Receive thread will draw for now). - -It is possible that states may be desired. For instance, there -would be the connection state, the one where the user and client -have to provide authentication information (this could be part of -connect phase perhaps), and in-game state. - -At first, as a test, the world will all be seen by everyone and -will fit into their screen. A world of 1024x768 could be used for -this :) Then there will probably be addition of a chat system with -messages window, to continue enhancing the protocol. Things will -go on from there... - -Hmm for now I want to simply use a joypad. -- Button 0 fires in direction of the paddle direction. -- Buttons 1 and 3 could act like button 0, to provide secondary weapon (1) - and special weapon (3). -- Button 2 attempts to correct navigation direction in the direction - of the paddle. -- Button 6 would accelerate. -- Button 7 would decelerate. -- Button 4 could toggle shields -- Button 5 could toggle cloak - -Equivalent keyboard layout: -- uiojlm,. would change angle just like the gamepad directions. -- w would toggle cloak -- s would toggle shield -- z would thrust up -- a would thrust down -- d would cause direction change -- space would torp -- f would fire second weapon -- g would fire special weapon - -And we're already out of buttons, we can't beam up/down armies or -bomb. Unless button 3 was special instead of a special weapon, -and allowed to perform various commands depending on the paddle -direction (i.e. up/down to beam up/down, left to bomb). This also -means that orbiting/launching would need to be automatic. Of course -all this is if we're thinking about a game like netrek. But we'll -simply only allow dogfighting at first. - -Now it becomes tricky how I'll minimize bandwidth sent from the -client to the server. Probably that buttons events will be monitored, -and then current paddle direction when required. In the case of -direction change button, the last paddle direction applied would -be remembered, and if the same, the event could be dropped. If -not, send a direction change packet. What happens if a button -remains pressed while a direction change occurs? We probably should -ignore it. +zlib is used to compress the communication protocol, and an RC4 +variant is used to encrypt. Threading limitations under win32 @@ -163,20 +53,9 @@ thread should perform the drawing, but it wasn't specified that another thread than the initial one would not be able to obtain all user input events on windows. Typed keys would not be received, for instance. -It then appears that most of the processing must be done in the main -initial thread, while only networking related blocking functions will -be done in slave threads. - -There also seem to be other windows-specific problems using SDL threads, -such as instability. I have noticed that when using another thread -for user events reception, part of the application would often lockup, -despite my code properly using mutexes as required, and all sound and -greaphics being performed by the main initial thread nevertheless. -These problems were also not found to occur on unix systems. - -The design was thus changed for now, and threads will be used for SDL_net -functions only, since they are blocking. Let's hope that this will work -stably, however. It remains to be tested. +It then appears that most of the processing must be done in the +main initial thread, while only networking related blocking functions, +or CPU crunching tasks, can be delegated to slave threads. Storing images and sound samples as part of the executable binary @@ -194,17 +73,6 @@ The SDL_mixer library however does not allow by itself to do this easily with music files. However, thise generally being considerably larger, it should not be a problem and they can remain external. -If this works fine, it would be easy to generate a cryptographic block -cipher key at build time and to include that key within the executable -as well. Copies of the binary files to be included could then be -encrypted using that cipher to a temporary copy which will be linked -in, and an initialization function could be provided to unencrypt the -files prior to use. Of course, since the key is also in the executable, -there is no real security. However, it could prevent computer-illiterate -people from too easily ripping our original content. RC4 could be used -for this for instance, or even a much more simple custom encoding -algorithm :) - Using a map =========== @@ -216,58 +84,3 @@ ship. This would prevent clients from being able to exactly fire at the actual ship position using the map (which also would make cloaking useful against an unofficial client). - -Encrypting communications -========================= - -A stream cypher such as RC4 would be simple and efficient to encrypt -communication between the client and the server. If RC4 is used, -the following must however be taken into consideration: - -1) Session keys must always be unique. To achieve this, a function -like HMAC to obtain from a long term key and a unique noonce could -be used if necessary. This however is best for private key -cryptography, I believe. - -2) The key must be renegotiated from time to time after enough data -has been sent using it. There exist vulnerabilities if 1GB of data -is transfered using the same key. - -3) At least 1024 bytes of the pseudo-random generator keystream -must be discarded after key creation to avoid a key predictability -vulnerability. - -If public key cryptography was used, at least 256-bit RSA could be -used. Such an implemetation theoretically would not need larger -numbers than 128-bit ones to function, I think. Then a "complex" -bignum library could probably be used which is faster and simpler -than a general purpose more complex arbitrary precision math library. - -We probably should borrow NetBSD's SHA512 (or at least SHA1) and RMD160 -algorithms. My ARC4 implementation could be used as well. - - -Compressing communications -========================== - -Investigate if using huffman compression would be wanted and worth -it, or some other simple compression system suiting well to the -transfered data. Possibly that the dictionary could be static and -would never need to be transfered. - -zlib could probably also be used. It however unfortunately is -famous for frequently discovered vulnerabilities. - - - -PROGRAMMING STYLE -================= - -The style chosen for this project consists of the (Net)BSD KNF style -(Kernel Normal Form) style borrowed from. All code should conform to it. -Additionally, lint(1)-style comments are used to make the code clearer -for future code auditors. - - - -Matt -- 2.9.0