I have figured out how to do Servlet to Applect and Applet to Servlet communication, but so far can only get it to read what is on the Servlet screen. Is there any way to have the applet read variables or something other than the servlet browser window? The reason I am asking is because people will cheat if the information is posted on the screen. With the servlet to applet communication I will have to have a servlet open for every game, which I was planning to have several games going at the same time...is there a better way of doing this, since wouldn't this idea bog down the server. Any suggestions or ideas are greatly appreciated.

First of all I don't understand what an Servlet screen is? A servlet has no form of GUI as it only response with HTML/XML or other standardize formats. Could u post the applet code?

I am quessing that you want to send information from one applet to the other applets? Or is it just posting presitance highscore?

If your using servlets to distribute information to the other players applets, there is another more prefered way to do this, but it requires acces to the web server. An applet can by it's default security sandbox only connect to the server that host the applet. So by creating a java application server that opens a TCP connection on a know port on the server the applets can connect to this port with TCP and send the information this way instead of posting with HTTP and reciving with a servlet. But unfortunate if you don't own the server or has root access to it you will not be allowed to install the application and open a port.

So what can u do to make the communication between an applet and a servlet more secure? If your using URLConnection to post to the Servlet it is easy for a user to use a sniffer and see what information it send and write it's own program to cheat. To aviod this there are numerous hash and cryptographically way to enforce a more secure communication. A simple way is to have a public and private key pair. The servlets has the private part and the applets has a copy of the public key. When a servlet is sending it's data it is being ciphered with the public key and sent. And the servlet decipher it with the private key. Then a possible cheater must get a hold of the private key which should be very time consuming. Search more on public-private keypair to read the basic math behind this. Also see the package java.security that has this implemented.

I suspect you have an applet loaded in a page which is generated by a servlet, and are using methods to read the HTML page from the applet (or similar) and not realising that the applet can simply send arbitrary commands / requests direct to the servlet, and the servlet can distinguish these from web-browsers and send back arbitrary data...

Quote

If your using servlets to distribute information to the other players applets, there is another more prefered way to do this, but it requires acces to the web server.

No need for this - you can upload arbitrary information to a servlet already. Just make the servlet accept POST, and make the servlet have a URL where requests get a list of all the data that's come in from the other applets.

Of course, I would suggest breaking up all these different aspects into unique servlets, since it would make it less confusing to edit...

Quote

it is easy for a user to use a sniffer and see what information it send and write it's own program to cheat. To aviod this there are numerous hash and cryptographically way to enforce a more secure communication. ...Then a possible cheater must get a hold of the private key which should be very time consuming.

Not at all - you just made the first mistake of security: assuming that the cracker/cheater will simply attempt the hardest possible way of breaking the security. No, only a foolish or naive cracker would do that. Instead, most go for the weakest link...

Give me five minutes and a page with your applet on, and I'll have decompiled the java code and probably have whichever key(s) I need. The time-consuming bit is going to be remembering the name of a decompiler which does de-obfuscation (if you haven't obfuscated, I don't NEED that part, but it can make up for any bad coding conventions you're using by assigning more meaningful names to some of the methods, variables, etc - so that I can read your source more easily), and then reading through your source code to find whatever secrets I need.

may i suggest you exchange serialized objects between your servlet and applet instead of html content...it's easier, more powerfull... and i guess it won't be displayable on screen but i'm not sure.here is a nice tutorial.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org