GameSpy supplies the game status code for the majority of on-line game servers. They sell an SDK which you can bake into you game to make it GameSpy compatible. Since many of the game servers are using this SDK, they're all capable of hosting a third-party DOS or DDOS. If they fix their SDK, then many games could release server patches and greatly reduce the problem. (so, this is very much a GameSpy issue, but the biggest game, Half-Life, does not use GameSpy SDK)
The best fix is a short-lived-cookie based protocol. But this will double the number of packets needed to get game server status information, and require client patches. A server-side throttling fix is best we can really hope for.
Using printf formats to handle I18N is a poor solution anyway. Some translations will require reordering of the parameters because of grammar differences. The message should include numeric arguments:
Some %1 thing went wrong with the %2.
Probably not a good example, but I can imagine a tranlation that need the %2 before the %1. With printf specifiers, this can't be done.
NT ([hiss]) does messages this way. You can only have string parameters, but you can easily write tostr(int) type functions for when you need to include numbers or dates in the string.
I guess I should fix my code to do '%' to '%%'
translation when I'm using syslog()...:-)
One of the Sun Java programmers once asked me, "So, what do you think of Java?" My response was, "It's a pile of crap."
I've been very frustrated with Java ever since it came out. It was born of excellent design and implemented some extremely valuable technology (VMs and GCs). But it was rushed at the end and the result was beauty encrusted with graffiti and hollow paper mache. So, I gave it some time...
Five years have passed. Some of the graffiti has been removed, but there is still a hollow tone to the base structure. It has been developing strongly in one direction while failing to deliver in other important areas.
Java delivers an excellent development language. It's no surprise that time-to-market sensitive apps have embraced Java. It's really good for that kind of thing: back-end, state-machine based, and atomic operations. Servlet programming is almost exclusively the only success story mentioned. That's a boon to webapp developers, but it does nothing for the other 95% of us.
Java's failures are numerous: Portability - The resources my company has saved programming with Java are consumed by QA. Each new platform is a significant expense. Our most recent release had to be staggered because there wasn't enough time to QA all the Java on all the platforms. Java VM vendors are largely to blame for this problem; we experience innumerable GUI portability problems (more below) and several nearly undebuggable oddities surrounding threads, file descriptors, and processes. And there are still vendors that lack a 1.2 JVM. Performance - It's much better than in 1.0, but still has enormous foot print problems. I see the time expended on Java performance work as equal to any other environment. Except that it's worse because of the lack of tools. If you stay away from GUI stuff and reduce your object "churn", you can get pretty good throughput. A JIT helps, but increases your foot print and reduces portability (from experience, JITs bring their own odd bugs, different on each platform). AWT/Swing - The GUI frameworks for Java are simply crap. It is impossible to develop a large scale GUI app that meets industry standards for performance and usability. Someone noted that Oracle8i has an all Java DB manager. As a marketing bullet it works, but fails utterly in practice. It's slow as a dog. Just try to navigate 100s of schema definitions. You and your machine will be paging like mad: you through your CD collection for that Oracle8 or 7 CD, while your machine pages the 80+MB footprint of the DB server and manager. And that's without installing any of your own DB tables or apps. --- Most of our company had to get RAM upgrades to run the new Swing based release of our software (from 64 to 128MB). Even so, the QA guys mutter and grumble daily as their machines grind away trying to bring up new panels and windows. How will our customers react? --- My comments about portability and performance apply most strongly to AWT/Swing. AWT was truly horrific. Many bugs were fixed during the 1.1 development, but many still existed. We had to hand code replacement widgets for several that were broken in AWT. Or do special per-platform and per-JVM bug work-around hacks. This was possible only because we have one guy that is brilliant at this kind of thing. It's no wonder there are no successful Java GUI apps. The bug parade is reduced with Swing, but at an extreme cost to performance. The minimum Swing footprint on Solaris is 12MB. Our large Swing based app weighs in between 30 and 60MB. An equivalent app on Windows with MFC is 8-12MB and is 10+ times faster.
There you have it, straight from the trenches. My company's greatest Java successes have been with the server-side code. This code is fairly thin and generally simple. Time-to-market is important in this area, so Java is the best solution. But our customers that need high performance stick to C/C++.
[Some what off-my-own-topic] One writer noted that the faster development cycle provides him with more time for performance work. My experience has been that a faster development cycle simply brings ship/deployment closer. The market goals for ship/deployment do not change; it's needed as soon as possible. So as soon as first ship is conceivable (minimum acceptable quality and features) is when it happens. That may come sooner in a Java based product, but the quality level ends up being the same. Or worse if it's a Java GUI app.
Improved server-side webapp development is contributing to the Internet commerce boom. This is no small accomplishment. Java will continue to succeed in this area. But will it be self-restricting? I see little investment in improving Java's client-side capabilities or fixing portability and scalability problems.
Background - My company has written and shipped 100s of thousands of lines of Java code. Most of it GUI code. I participated in only a small portion of this development. The requirements for my part of the product do not mesh with what Java offers, so I use C++.
Slashdot Mirror
GameSpy supplies the game status code for the majority of on-line game servers. They sell an SDK which you can bake into you game to make it GameSpy compatible. Since many of the game servers are using this SDK, they're all capable of hosting a third-party DOS or DDOS. If they fix their SDK, then many games could release server patches and greatly reduce the problem. (so, this is very much a GameSpy issue, but the biggest game,
Half-Life, does not use GameSpy SDK)
The best fix is a short-lived-cookie based protocol. But this will double the number of packets needed to get game server status information, and require client patches. A server-side throttling fix is best we can really hope for.
Some %1 thing went wrong with the %2.
Probably not a good example, but I can imagine a tranlation that need the %2 before the %1. With printf specifiers, this can't be done.
NT ([hiss]) does messages this way. You can only have string parameters, but you can easily write tostr(int) type functions for when you need to include numbers or dates in the string.
I guess I should fix my code to do '%' to '%%' translation when I'm using syslog()... :-)
The %1 in the example would be "damn" in english.
I've been very frustrated with Java ever since it came out. It was born of excellent design and implemented some extremely valuable technology (VMs and GCs). But it was rushed at the end and the result was beauty encrusted with graffiti and hollow paper mache. So, I gave it some time ...
Five years have passed. Some of the graffiti has been removed, but there is still a hollow tone to the base structure. It has been developing strongly in one direction while failing to deliver in other important areas.
Java delivers an excellent development language. It's no surprise that time-to-market sensitive apps have embraced Java. It's really good for that kind of thing: back-end, state-machine based, and atomic operations. Servlet programming is almost exclusively the only success story mentioned. That's a boon to webapp developers, but it does nothing for the other 95% of us.
Java's failures are numerous:
Portability - The resources my company has saved programming with Java are consumed by QA. Each new platform is a significant expense. Our most recent release had to be staggered because there wasn't enough time to QA all the Java on all the platforms. Java VM vendors are largely to blame for this problem; we experience innumerable GUI portability problems (more below) and several nearly undebuggable oddities surrounding threads, file descriptors, and processes. And there are still vendors that lack a 1.2 JVM.
Performance - It's much better than in 1.0, but still has enormous foot print problems. I see the time expended on Java performance work as equal to any other environment. Except that it's worse because of the lack of tools. If you stay away from GUI stuff and reduce your object "churn", you can get pretty good throughput. A JIT helps, but increases your foot print and reduces portability (from experience, JITs bring their own odd bugs, different on each platform).
AWT/Swing - The GUI frameworks for Java are simply crap. It is impossible to develop a large scale GUI app that meets industry standards for performance and usability. Someone noted that Oracle8i has an all Java DB manager. As a marketing bullet it works, but fails utterly in practice. It's slow as a dog. Just try to navigate 100s of schema definitions. You and your machine will be paging like mad: you through your CD collection for that Oracle8 or 7 CD, while your machine pages the 80+MB footprint of the DB server and manager. And that's without installing any of your own DB tables or apps. --- Most of our company had to get RAM upgrades to run the new Swing based release of our software (from 64 to 128MB). Even so, the QA guys mutter and grumble daily as their machines grind away trying to bring up new panels and windows. How will our customers react? --- My comments about portability and performance apply most strongly to AWT/Swing. AWT was truly horrific. Many bugs were fixed during the 1.1 development, but many still existed. We had to hand code replacement widgets for several that were broken in AWT. Or do special per-platform and per-JVM bug work-around hacks. This was possible only because we have one guy that is brilliant at this kind of thing. It's no wonder there are no successful Java GUI apps. The bug parade is reduced with Swing, but at an extreme cost to performance. The minimum Swing footprint on Solaris is 12MB. Our large Swing based app weighs in between 30 and 60MB. An equivalent app on Windows with MFC is 8-12MB and is 10+ times faster.
There you have it, straight from the trenches. My company's greatest Java successes have been with the server-side code. This code is fairly thin and generally simple. Time-to-market is important in this area, so Java is the best solution. But our customers that need high performance stick to C/C++.
[Some what off-my-own-topic] One writer noted that the faster development cycle provides him with more time for performance work. My experience has been that a faster development cycle simply brings ship/deployment closer. The market goals for ship/deployment do not change; it's needed as soon as possible. So as soon as first ship is conceivable (minimum acceptable quality and features) is when it happens. That may come sooner in a Java based product, but the quality level ends up being the same. Or worse if it's a Java GUI app.
Improved server-side webapp development is contributing to the Internet commerce boom. This is no small accomplishment. Java will continue to succeed in this area. But will it be self-restricting? I see little investment in improving Java's client-side capabilities or fixing portability and scalability problems.
Background - My company has written and shipped 100s of thousands of lines of Java code. Most of it GUI code. I participated in only a small portion of this development. The requirements for my part of the product do not mesh with what Java offers, so I use C++.