Deploying Java Applets
(Page 1 of 5 )
In this second part of a three-part series on using Java with deployment frameworks, you will learn how to deploy applets in a self-contained manner, and what they are and are not typically permitted to do once they are downloaded. This article is excerpted from chapter two of
Advanced Java Game Programming, written by David Wallace Croft (Apress; ISBN: 1590591232).
Knowing Your Limitations
Browser applets run within a security sandbox on the client where they can play without being able to cause harm. This means that there are restrictions on what an applet can do. Much to the relief of users surfing the Web, downloaded applets do not, for example, have read and write access to their hard drives. To prevent applets from using the client machine as a platform to stage an attack on other machines on the Internet, applets can only create network connections back to the server from which they were downloaded. Keep in mind that the server contacted must be the same one from which the applet was downloaded—the codebase—which is not always the same as the server for the HTML web page that contains the embedded applet—the document base.
There are other additional restraints but these are the two that might be the most onerous to the game developer. The inability to access the hard drive makes it impossible to save the high scores or the preference settings for a player. The inability to contact machines other than the applet server means that game applets cannot contact other peer machines directly for multi-user game play.
The way to get around both these limitations is to perform these functions through the applet codebase server. After prompting the player for a user name and password, the applet can make a network connection back to the applet server to load user data. Later the applet can make another network connection to save the game state on the server when the player chooses to do so, or automatically at periodic intervals during play. In the case of multi-user play, all messages between players are routed to each other indirectly through the central server. For example, when the sprite of one player moves in a virtual space, the applet views of the other players are updated by a message passed first from the acting applet to the applet server and then from there to the receiving applets.
Applet networking, including applet-servlet messaging with firewall tunneling capability, is covered in detail in the last three chapters of this book.
Signing Applets
You can make the applet security restrictions go away by digitally signing your applet. Digitally signing your applets permits the framework to authenticate that the applet was created by you—the developer—and not by someone posing as you. It also allows the framework to verify that someone else has not modified it since you created it. Once authenticated, the applet framework, such as a browser or the Java Plug-in, then prompts the user for permission to run the applet without any limiting security restrictions.
If the user grants this permission, the signed applet is said to be trusted. Unsigned applets, then, are run in untrusted mode. I find this confusing as the only applets I trust are the unsigned applets running within the restrictions of the security sandbox. When you consider that the authentication safeguard is not foolproof, granting an applet complete access to your machine seems foolhardy.
But do not let me discourage you from signing your applets. You might be discouraged instead by the fact that support for digitally signed applets varies from browser to browser and sometimes requires a browser-specific signing process. Additionally, you might need to pay a few hundred dollars to a trusted certificate authority so that you can be positively identified. Finally, you might want to consider the reaction of your more paranoid and privacy-conscious users when they are prompted to decide whether to give your game applet complete control of their home or workplace computers.
For more information on signed applets, please see the Java Plug-in Developer Guide for J2SE 1.4.3
Caching Applets
One of the main advantages of applet distribution is that the latest version of your code is downloaded every time users play the game. On the other hand, one of the main disadvantages of applet distribution is that your code is downloaded every time users play the game. What you need, then, is for browsers to cache the applet and only download your code again when a new version is available. Although browsers have always been able to cache web pages and images between browser sessions, this has not been the case for applets. When the user would close the browser window, the browser would discard the applet download, most likely for security reasons.
In the past I have written custom code to implement applet caching. This involved digitally signing the applet and intimate knowledge of the different security policies of the major web browsers. Nowadays, however, custom code is no longer necessary as the Java Plug-in supports applet caching. I cannot vouch for the effectiveness of this feature as I have not used it but the documentation describes it. If your applets are fat and your users are using slow Internet connections or you just want to save on bandwidth-distribution costs, the applet caching mechanism of the Java Plug-in is definitely worth investigating.
Next: Deploying as an Executable JAR >>
More Java Articles
More By Apress Publishing
|
 This article is excerpted from chapter two of Advanced Java Game Programming, written by David Wallace Croft (Apress; ISBN: 1590591232). Check it out today at your favorite bookstore. Buy this book now.
|
|
/ 6 
