Moa

As I've mentioned before I'm working on a (limited-scope) modern jet sim myself. I considered using a HTTP-based server (using the excellent Google Web Toolkit) but decided not to. To make an useful (and secure) web-based program requires use of an application container, such as Apache Tomcat. Setting this up is not that hard, but too much if you are not used to it. The Jetty embeddable server is an alternative, but to be honest I'm not that fond of it (compared to Tomcat). Presenting a web interface means more hassle for deployment. In the end I decided to make a GUI for the server using the Swing toolkit (which I find very powerful and very productive) since I can bundle this as a single file - which makes deployment very easy. I considered making a 'headless' version, that would run from the command-line only. This has advantages if you are making thousands of servers but these days being headless has little advantage for the small number of game servers. What does make a difference is a server that doesn't require a DirectX 9 capable card with at least 512 MB of VRAM. Not having this requirement means you can run in a virtual machine and is vastly cheaper than running a LockOn/DCS server where you need to co-locate a machine that has a decent 3D card onboard (costs around US $100/month). Fortunately DCS has been moving towards a server mode that can run in 2D - I think a 3D card is still needed for installation (although I haven't confirmed this).

Please also note the default port number for DCS:A-10C is 10308, although you can change the port number on the server hosting screen. The port number that you forward on your router must match whatever port you configured in A-10C on that server hosting screen.

Excellent! please keep up the great progress.

Is session id just an int? or is it more complicated, including a 'nonce' timestamp to prevent replay attacks? Thanks for talking with us c0ff.

This is already possible to get a UCID on connection, as you probably already know. Sometimes the UCID seems to come through with a different value for the same person - I haven't checked whether that is a bug in my stats code (which logs all connections) or it really is sent with a different value sometimes (as far as I can tell it is the latter, but I can't rule out the former - I have to check the original log entries, which I also store for just such purposes). The recent problem with the hacker was that they could send packets to the server and the server would accept them, and crash. I don't know whether the sending hacker/user was authenticated or not - from c0ff's reply it seems he must have been authenticated, so it would be nice if UCID's that send invalid packets are logged. This crash on a specially crafted packet has been fixed. Apparently the server drops all packets for unathenticated users, expect if it is a *valid* authentication request. Unfortunately there is no information on how to derive UCID from an arbitrary packet. Perhaps the UCID is transmitted on each request, I don't know the network protocol so don't know whether client identification information is part of each packet or not. If a UCID isn't transmitted then it makes it possible for packets to be sent anonymously (except the established connection means they must have authenticated in the past, but it doesn't mean modders can derive the UCID from the connection). Note that better than a UCID is a 'session token' which can be resolved to a UCID. A session token has the benefits of being time-limited (unlike a UCID) and can contain an encrypted or hashed UCID so the UCID isn't transmitted in the clear. That way you don't have to use TLS for the rest of the packet (since TLS makes network comms slower if you are using encryption).

From your responses it shows you are not getting my point (elaborated by Aldega to try make it clearer to you). There are two kinds of validation you can do: 1) development time: unit tests, integration tests, and 2) runtime checking. Clearly you wouldn't validate the A10C flight model at runtime - this would be done with hundreds of unit tests on the flight model trying all sorts of flight conditions from normal flight to negative airspeed tail-slides (you have these, don't you?). At runtime would validate the *inputs* to the flight model, eg. do the parameters loaded from config make sense? these checks can't be a straightjacket, but checking against null or non-sensical values would help program robustness. Also at runtime you can check the *input* from the client across the network. Has the client said he's launched a missile when the server knows he's already launched his complement of missiles. Has his position changed so much that he could only have got there are Mach 25 etc. These are really basic things that hackers are currently exploiting. It would take microseconds to check these. Why are we making these unasked for suggestions? Well, the DCS concept is fantastic product and we want to make it better. The DCS implementation at the moment is improving but doesn't give a great experience in multiplayer. In some areas recent patches have made stability go backwards. We have noticed significant multi-player bugs that basically makes the multi-player experience unusable for our purposes. I have done the hosting and set-up for the three large-scale A-10C Fly-Ins, so possibly have more experience that anybody at running large-scale [30-50 player] DCS multi-player events. This makes me feel qualified to make some comments about the multi-player experience. Now giving specific examples is hard since I have no source code. If I did I'm sure I would have many suggestions. I don't so can only give 'black-box' testing comments. Here are some suggestions. They are meant in a spirit of constructive criticism. As a fellow developer I know that some criticism turns out to be invalid due to other concerns, but at least some of it is valid. Also, I don't think the security issues are totally isolated with the general approach to stability - since it is the overall experience that your customers see. 1) Validate all your inputs. From the network and everything read from disk. Concrete example: if you change monitors the program can't cope and crashes on startup (without displaying anything sensible or logging anything). A simple check comparing the configured value and the detected monitor resolution would prevent this problem. At the moment the forums frequently get questions about crashes on program startup because of the simple lack of checking. All parameters ought to be checked this way (if you'd used XML instead of Lua tables then an XSD would be a great help for validation, plus give information about the problem). Unfortunately the choice of Lua means that many data input problems slip by without Lua warning you. Look at the 'options' files in the FC2 missions. They have a varied set of option fields (indicating the missions were probably developed during different internal FC2 builds where the options structure was changing). That means some parameters are not being set in some missions. If you have random initial conditions starting a game of course you are going to get stability and reliability problems. A validating check on mission load would have picked these up during 'development' and helped you write a more reliable program. The information read from the network needs to be validated too - this includes coping with 'short reads' (getting fewer bytes than expected) and formatting inconsistencies (buffer lengths reported don't match actual buffer lengths). It is interesting to hear you say that this has been done since LockOn 1, since the recent experience is that a few bytes sent to a FC2 (and presumably DCS) game server could crash it (thankfully fixed by the recent patch). Somehow I can't quite reconcile those facts - I must be missing something from the picture. 2) Clean up all the broken references to resources. In the logs there are all sorts of warnings about missing references to resources. Not only does this decrease the signal-to-noise of the logs (hard to pick out important messages from the general stuff), it also shows that the program can't be operating as expected, since some of the things it needs are not present or in a different place. The solution is not to suppress the logging, it is to get the people responsible for maintaining the references/paths to resources to go through and fix the paths. The program will never be stable without this. 3) Improve logging. In the case where the monitor resolution is blank or invalid no message is logged, the program simply quits. Since you are validating your inputs you'll log what the read value was and what the program thinks the valid range is (sometimes you can have a bug where the program is getting the wrong check values). Without having good logs it makes your job harder, since we can't give you the information you need to fix hard-to-find bugs. 4) Build for an imperfect network environment. Requiring continuous connection to the master server will always result in an unreliable program (in internet parlance this design is a 'fail'). No one can make the Internet perfectly reliable, so you mitigate this with ways to cope with the unreliability, while still achieving the aim of only allowing valid customers to use the software. I've already pointed out a way to do this. So, I can't tell you which lines of code to change and can only give you suggestions. I hope I've given you some concrete examples to illustrate what I can see as issues that could be fixed pretty easily - improving both program reliability and hacker resistance. The code base is too big to make validation changes to all at once. What can be done is that all *new* code gets unit test coverage where it can (sure, not all game code can be - especially rendering and GUI - but much can), and validation of critical inputs and state (known as 'checking preconditions'). Again, these comments are not intended to give you a bad day at work. I think DCS is a very impressive bit of software. I do think it could be made more reliable and some of the faults are fixable by using systematic practices rather than ad-hoc fixes later. From what I observe of the programs behaviour it appears that some development practices I have suggested (automated testing, validating inputs, making log quality important) could be used or improved. I do believe that it will make the life of ED developers easier in the long run, result in a better product, and give a better customer experience. More satisfied customers means more sales as the series progresses because *positive* customer buzz generates revenue.

While we're talking, this 'requirement' means you will never have a reliable system. It is better to not have this as a design goal. The software ought to be built assuming that the connection can be temporarily interrupted. The internet is unreliable (for very many reasons) and the software must take this into account. Authentication over the unreliable internet is a very well known problem for internet-scale applications. Generally they have a time-limited session token of some sort. Once you have authenticated you remain authenticated until your session token expires. Of course, servers can expire a token at any time so they still have control, it just means the client doesn't need continuous connectivity. Before expiration the client software can either kick you off (old style and hostile) or attempt to re-authenticate on your behalf in the background. For example you could have a 1 hour session token that tried to re-authenticate in the background after 30 minutes and re-tried every 5 minutes or so until successful or the 1 hour session was up. Plenty of 'enterprise' applications are built to work this way (I know, I've written some). Using sessions also takes the load off the authentication servers. Meaning they can be *very cheap* virtual machines - which allows you to have more of them for redundancy. Of course, for reliability you'll have several authentication servers in geographically diverse areas (eg. California, Singapore, Frankfurt). If one server cannot be reached then the others are tried (in a DNS-like fashion). Not only will this give you reliability (no more 'players can't connect because the single master server is down' stuff) but it also allows you to pull authentication servers down for maintenance or upgrades while the others stay up. The geographic diversity is necessary because undersea cables can be snagged or significant earthquakes can happen (California!) taking a whole area out. So you need to spread your servers around a bit. Doing this is very reliable, cheap, and good for players (they can always connect no matter what Internet storms there may be). Rather than provisioning your own servers/VMs you can also use services like Amazon's EC2 which is pretty cheap and scales well with variable load. This post is not intended to tell ED how to run their business, I'm just passing on what I've learned about how other outfits with international customers run theirs.

Thanks for replying c0ff. Last weekend I heard second-hand about attacks on a server during the weekend. I presume this server had the recent patch (although I could be wrong). The hack was apparently even able to log in to the server and post taunts. My own server appeared to be attacked as well (I'm still sorting through the evidence to see if it was coincidence or not). This server was patched. If the packets from an unknown source are being dropped I can't see how these attacks are possible - there is something missing from the picture - unless the user authorization scheme has been compromised (!?). Also, encrypting normal traffic is not required for the scheme I outlined to work. Only the initial handshake needs encryption, and even then you wouldn't need TLS, just mutual authentication with some randomly generated text (nonce protected, of course) and the rule that connections cannot be established without master server authentication. That would be enough to set up the internal 'firewall rules' within the application. If you are not an authenticated client your packets should be dropped. It didn't appear that was happening pre-patch. Packets were being parsed by the server even from non-authenticated sources, which could cause the server instance to fall over. Those malformed packets should have been dropped before they got to that stage. I haven't checked post-patch but the fact there was chaos last weekend means things still don't appear to be water-tight. Thanks for the efforts of yourself and your colleagues to improve the security of the game. Unfortunately the way the servers advertise themselves on the master server list means we can't write our own filtering proxies unless you also do port-forwarding, which not everyone can do (I thought about writing such a proxy last weekend).

I gave up modding for DCS/LockOn (and slowed down VNAO modding) and started work on my own simulation. I intend supporting two seat operation of aircraft. I have no release date yet as I've only been working on it for three months and want to make no promises (I'll cut features to get the first public release out the door, if I have to). I hope for something simple (two flyable aircraft, quality between FC2 and DCS) at the end of the year - but no promises. The only thing I will promise is that I will release something eventually. I'll give more details later in the year so expectations will match my implementation. Meanwhile dream about multi-seaters, and support ED. @Riptide: thanks for posting that link.

Here is what I hope for Flaming Cliffs 3: a) all packets received by the server are dropped unless: 1) the server has an established connection to an authenticated user at the sending IP address, or 2) the packet is a *valid* request for authorization. b) all accepted packets are inspected for correctness. Both format is checked (to prevent mismatches in stated sizes etc which could cause null pointer crashes or buffer overruns) and basic validity in terms of game logic (does the packet request an illegal missile launch either by number of missiles launched or missile type, etc). In this way a hacker cannot exploit the game even if they do hide behind proxies (the current situation). At the moment a player can "board the aircraft without showing their passport". This is not a good security model. Even if a hacker somehow gets through this you will always have their authenticated ID. Then you can ban their ass on the authentication server without putting the onus for security on the individual game servers. Problem solved. Permanently. Yes, you need additional CPU to inspect the packets. Run this on one CPU core and hand off the valid packets to the other core (running the game). Then with the core doing sound you'll still have cores 'twiddling their thumbs' with idleness. The server should never trust the clients. This security model makes it so.

I think whatever is next in Flying Legends is likely to be from the Fighter Collection's stable. That way they can get all the data they need (performance, object dimensions, sounds etc).

That is a very interesting idea sobek. I'm very curious (please note, no malice whatsoever intended here) - could you please elaborate with your thoughts are on this. Your comments may not only satisfy my curiosity but they might help some other readers understand why they shouldn't expect to always max settings out on x-plane 10 or other sims (eg. DCS). Thanks.

+1 aaron886. Well spotted. How can someone have had enough interest in aviation to join these forums and completely miss the fact that most warbirds are very frequently named after saucy women or have them painted on the side? Is "Enola Gay" too lame for you weasel75? despite it being the meanest individual bomber used in anger (if we are callous enough to go on bodycount alone). Is "Glamorous Glennis" also too lame? despite it being the first controlled supersonic aircraft? Don't worry weasel75, I only mean to tease you, please don't take this too seriously. Have a look around for famous named aircraft on the InterWebz, you'll find a lot of great names - and some funny ones too.

You can often find nice photos on the official US Defence Department pages for each force. As I understand it the photos are in the public domain, thanks to the generosity of the US taxpayer. USAF http://www.af.mil/photos/index.asp USN http://www.navy.mil/view_photos_top.asp US Marines http://www.marines.mil/news/pages/photos.aspx US Army http://www.ahco.army.mil/site/photos_brief.jsp Look for F-35 shots in the USAF and USN pages (amongst the other goodies). Enjoy.

This is correct. This happens when a recursive function is called (a function/method that calls itself). Each time it is called the return address and arguments get put on the stack. This is ok provided that at some point the function stops calling itself (which it will know how to do if it modifies the arguments it passes to the next instance of itself). If the self-calls never stop then the data placed on the stack grows and grows until you run out of stack. Then you get this stack overflow error. The size of the *stack* is not related to the size of your *heap* memory. The stack size is usually set at compile time (for C/C++ programs, in Java it can be resized on program startup), and is usually around 32kB - 64kB in size (yes, that is *kilobytes*), while the heap size is whatever spare memory you have left (eg 4 GB). A stack overflow is not related to how much RAM you have on your machine, what other programs are running, or how long since you re-installed DCS. It is related to a bug in the code (or game data) that causes the recursion to occur 'infinitely' (that is, until you run out of stack space and the program can no longer continue). Recursion is a nice feature. With some effort recursive solutions can often be re-cast as iterative solutions (using loops instead of self-calls). The code for interation can be less elegant but is often much safer - and it is easier to spot cases where there is no terminating condition. Frem bitter experience I personally always prefer to use loops (even ugly ones) to elegant recursion for this reason.

Please try the mediafire link again from that page, nick10. It works for me (just tested it).

Here are some interesting tidbits about the Chinese defense posture, AFAIK: * the growth in budget is in line with their growth in GDP. So this is not so sinister. * the cost/man in Chinese defence forces is lower than comparable countries. That means either the figure they have underestimates their manpower, or they have been building forces greater than their budget indicates, or that they get more bang for the buck (take your pick). * while China has made noises about not wanting to take Taiwan by force, they have increased the number of ballistic missiles on the coast opposite Taiwan dramatically. They are also working hard at a decent navy and amphibious forces. They are certainly giving themselves options. Unfortunately there is a 1979 law which compels the US to defend China in the event of a Taiwanese invasion. So the Chinese havei been working on their carrier-killer ballistic missiles (modified DF-21) to counter this. * the posture of the Chinese in the South China sea has been very aggressive. Often 'fishing' boats have been used to ram other vessels out of the way. Marines have also been sent to claim unoccupied reefs even in international agreements have assigned them to another country or they are disputed. This has received very bad international press (by those paying attention) and China has noticed and backed off somewhat (which does lead to the question of whether the aggression was sanctioned by authorities - which would be very bad). * China pretty much claims all of the South China sea, right up to the borders of countries like the Phillipines (that is, far from China). * China has been contributing to UN peacekeeping and anti-piracy efforts. * the growth in China's navy appears to be an understandable need for greater deep-water capability to protect the raw materials their economy needs. If their economy falters they know they will have great internal trouble - hence they depend on frail supply lines far more than many realise, and they are planning to ensure that sea lanes are kept open (generally, every nation wants this). * China is currently stealthily infiltrating Indian territory in and building up strength and facilities in the region. The Indians don't want to cede more territory to China like they did in the last war. If China gets into a brawl it could well be here. This post is not mean to be anti-Chinese or judgmental. I'm trying to report what I understand are facts about recent military behaviour in South East Asia - since this may be a significant flashpoint in the future. I hope you glean it is a mixed bag. Some things are rational and positive developments. Some do sow doubts on their somewhat inscrutable ultimate aims.

Thanks Bearitall. The direct link for the current VNAO mod is: http://stallturn.com/wiki/en/VNAO_mods The stallturn server still runs missions supporting the VNAO mod. We had half a dozen guys on yesterday, and you can see casual activity has picked up last month (due to some of the other servers being moved [104th] or temporarily shut down due to the FC2 hacks) VNAO scoreboard: http://stallturn.com/scores/ Note: the free Java download from http://www.java.com is required to see the scoreboard

Thanks for the fix ED. I found that it *does* require re-activation. Since my server has just run out of activations adding the patch killed it, and means I'm offline until I can get a new serial. Stink :(

Lol. For those that don't get this joke either, it is from the recent (and excellent) game 'Skyrim'. Here are some Youtube videos to help find the humor in the 'meme' this joke uses: http://knowyourmeme.com/memes/i-took-an-arrow-in-the-knee (sorry to explain a joke, but it'll be 'wtf' for plenty - and I thought explaining it might help some folks understand what a nice joke it was).

What are you guys smoking? :) ED Nevada looks great, and it is populated with 3-dimensional stuff too! and clouds, and objects to destroy, and has a nice sky gradient that varies with time, and lamps, and dynamic illumination (not shown), and utility vehicles/starter units, and ... and ... From those pictures it is clear that the ED stuff is the more advanced terrain system.

Hopefully the Java modding interface will let you resolve such annoyances (I've yet to check it out in detail).

Incidentally, Take on Helicopters can now be scripted in Java: http://forums.bistudio.com/showthread.php?128800-Take-On-Java If this works out to be successful Bohemia Interactive may make ArmaIII 'scriptable' in Java as well as the existing script language. This will allow for some great extensions to be made. Note, the 'scripting' in Java is not actually what a developer would consider 'scripting'. It is fully compiled extensions to the game - which allows more functionality, much faster running, and far less defects (since the compiler can catch them). This is an excellent move by Bohemia Interactive.

It looks like ED are set to address this issue - there are clues if you look at the rationalization of the formats for Simple Flight Model aircraft (which is good enough for most purposes) in the BlackShark 2 directories. I'm sure ED are continuing work in this vein as they move toward future projects. I'm keeping a close eye on this as I did get fed up with modding ED products due to the limitations, bugs, and lack of full documentation of the interfaces - plus my pathological dislike of Lua (I hate weakly typed programming languages and the lack of decent Lua tools and libraries). But there is a hope that ED are sorting this out now - so they deserve credit for this and our patience, so they can complete whatever they have planned without us hassling them too much. Meanwhile, I'm not sitting on my hands and have started a project to produce a jet combat flight sim by the end of this year. I have already had a lot of help from fellow simmers that are aware of the project and are helping out in ways they can (gathering technical documentation, offers to test things for me; thanks especially to 104th_Presing, A.S. and 104th_Crunch). I'm sure it won't be anywhere near as good as DCS:Jet, whenever that arrives, but it will be something and the client will most likely be under a GPL license. It will also be a base we can work from, slowly but surely. The server cannot for security reasons (recent FC2 hacks attest to this). My reason for starting something is that if the community never starts a combat simulator then in five years we'll still be in the same boat as now (no community combat simulator). Meanwhile, please support ED by buying their products (no-one pirate, kk). We want to have lots of viable simulator choices if we can - for our hobby, 'less is more' does not apply, more is more.

When you retract your flaps your rate of climb will decrease. If you are slow and have a small rate of climb then retracting your flaps may actually result in a sink (small decrease in altitude). Needless to say this can be dangerous - so don't retract your flaps just after you have gear up (unless you are on afterburner, which the A-10C doesn't have, and quickly nearing your flaps out speed). The usual rules on takeoff are: 1) Once you are airborne and have a positive rate of climb then retract your gear (this is almost immediately after you leave the runway). 2) Once you are airborne, have a positive rate of climb, and reach a minimum altitude (could be as low as 200 feet, could be 500 feet) but before you reach your maximum flaps out speed then retract your flaps. Any sink will not be significant. Plus, by leaving your flaps out for a few tens of seconds after takeoff you are better configured to handle a dangerous EFATO (Engine FAilure on Take-Off) situation and attempt a forced landing.