So, we've tossed around ideas like RakNet replacement and such for a while, but no one has yet stepped forward to say that they think they can single-handedly spearhead the replacement. Maybe that's the wrong approach though. What I'd like to do is maybe get some sort of 'analysis by comittee' going, where anyone interested checks in on this thread or whatever and we try to get a group understanding and documentation of what's going on. If we were ultimately going to use RakNet, the idea would probably be to start with replacing the in game network code module, and since that seems to be the part of the code that, until fixed, renders any other efforts towards multiplayer kind of moot, I think it's the best place to start.
But let's assume for a minute we don't need to use RakNet. I've been theorizing lately about this. We did not one, but two go_fasters for the graphics code, which both found some low hanging fruit and serious drains on the framerate, and fixed them in a series of individual enhancements, which led to massive gains. Many of these were fixes for features that weren't optimized to begin with, or were optimizations on the original framework. I think something similar might be possible for the netcode. FS2 multiplayer was popular back in the day, so (someone correct me if I'm wrong) it had to have been playable to some extent. But what we see today seems to me like something no one would have put up with. If that's the case, then perhaps the changes over time to the game have actually degraded the behavior, and we need to figure out where and how, and try to speed it back up. Even if that's not completely the case, I think we can still start with analyzing the current netcode performance, be it with enhanced logging, tracing, debugging, whatever, and attempt to identify some of the areas where the netcode might be having hiccups.
For instance, I ping my dedicated server, and see times around 35ms. In game, FS2 reports my latency as 250-300ms. What on earth? Is this just because of a different transport layer, or is the code really injecting that much overhead just to ping? If that's the case, is there similar overhead in game? There's really no excuse for that if that's the case.
Also, from what I've seen, packets have had to grow to handle things like additional SEXPs and other expanded information over time. Could these larger packets be slowing down client-server communication significantly at this point, resulting in significant degradation compared to retail? If that's the case, perhaps we need to analyze how we send that kind of data and determine if there are ways to shrink the packets.
Are packets compressed? If not, we have zlib already for png, could we use zlib to compress larger packets? I think most modern computers can compress/decompress fast enough to make this a worthwhile consideration to get faster data transmission.
We could get a network logging/debugging branch going on Github to collaborate our efforts, if anyone has any ideas for a good place to start putting some logging facilities in.
So what say you all? Anyone else here interested in doing a grass roots team effort towards network code refactoring?