Client/Server delegation

Hey Java guys,

I'm really not sure which category this thread should go in. I'm technically new to Java but have been programming for almost ten years now and have a fairly intimate knowledge of Java thus far, so it could be Advanced Java. Might also be "Java Applets" as this is for an applet, or it could be Networking because it's client-server-related. (If a moderator could move this to the appropriate section that would be great.)

I'm currently working on a networked game; I'm trying to delegate the common tasks between game and server and am having some difficulty deciding how to do so.

I'm not sure exactly how secure Java code is once it's put on the Internet. Because of this, I think the best option is to dissect every function in half, such as:

Java Code:

// Code to drop an item from player inventory.
public void Drop() {
if (base.app.IAmServer) {
// In this case, the applet/application running is the server.
this.Discard();
base.world.GenerateObject(this.GetId(),base.player.X,base.player.Y);
} else {
// Not the server; this code executes if this is the client.
csPacket.Make().SetCat(CS_CAT_REQUEST).SetType(CS_TYPE_DROP_ITEM).SetData({ this.m_Slot.GetInventory().GetId(), this.m_Slot.GetId() }).Send();
}
}

The problem with using this is that now, the server's code as well as the client's code is available in the client applet running in the web browser.

Having only the limited knowledge of Java security that I do, I'm not sure that this is really a good idea, though it seems like the best implementation. (I can run the same software on the client and server and simply change IAmServer between true and false.)

Alternately, I could split up the libraries entirely but that makes development a bit of a pain in the ass, for the simple reason of having to switch back and forth between libraries and having to make changes to two sets of code.

So I guess I'm really looking for some advice here; does anyone have a better solution as to what the client-server code delegations should be?

When comes to the Java EE technologies web container provide extensive capabilities to the web server. So that implementing HTTPS communication and stuff are so easy, provided secure communication chanel.

If the applet code is in a jar file or class file, it can be downloaded and decompiled.
The source code can be scrambled by a (???) to make it harder to read, but anyone with a decompiler can still see it.
Best to keep much of the code on the server if you want to hide it.

point is: what you give to the user can the user see.
The question is if its worth bothering.
you know how hard it is to read java bytecode? I don't think one would put that much work in it.
If you want it completely secure: create your whole logic server side and use the client side purely for rendering.

point is: what you give to the user can the user see.
The question is if its worth bothering.
you know how hard it is to read java bytecode? I don't think one would put that much work in it.
If you want it completely secure: create your whole logic server side and use the client side purely for rendering.

I was definitely planning on it; the IAmServer and IAmClient logics just make it much easier to manipulate and design both the client and server software.

I think for the time being I will store all code in the client and perhaps in the future split it up (despite that possibly being a fair bit of work)... I will also look at obfuscators as mentioned by Norm to scramble the code further.

point is: what you give to the user can the user see.
The question is if its worth bothering.
you know how hard it is to read java bytecode? I don't think one would put that much work in it.
If you want it completely secure: create your whole logic server side and use the client side purely for rendering.

Why are you really bother to read Java bytecode, de-compilers done the tricks on class files. It's much easier.

I agreed with you up to a certain level. Most of the freely available decompilers not generate the correct source code, probably with few errors. But some of the advanced decompilers are also available, but you've to pay. And also in most of the cases, experience developers can fix those errors.

I think dinosoep is right; what the user can see, the user can see. If a bit of your code slips in C++, it's not as big of a deal (though using assembly and such you can get a general syntax of the program). But like you suggested, because Java runs on a VM, the user can decompile all the code just as the VM would (with a small margin of error).

In the end I did come up with a method to make the libraries easy to edit and still refrain from giving the user the server's code.

Every main class (SomeClass, for example) has methods containing the client's code, in the server and the client. If there is any server code attached, it is @Overridden in a "ghost class," something like: SomeGClass extends SomeClass (in the client, SomeGClass would just be an empty class). Then you can just extend SomeGClass which contains all of SomeClass's methods regardless of whether it's the server or client.