Java design question
Hi,
I'm new at this, so sorry if I抦 a bit uneasy to understand.
I need to write a little program that simulates an online server with a game. The user and the server are communicating with certain protocol syntax, every command sent by the user should be addressed to the game, which then executes the command.
What I want, is to have flexibility in replacing the game implementation, so that if someone writes a new implementation for the game it could be easily fitted into the server, with the server's protocol.
My question is how to put restrictions on the game, so that anyone that writes a new game would have to comply with the server抯 protocol (i.e. for every command in the protocol there would be a corresponding command in the game). And on the other hand, if the server抯 protocol changes the game restrictions should change accordingly.
I抳e tried thinking on how to do it with Interfaces, but I don抰 see a way of binding a game Interface with a protocol Interface/Class.
Thanks in advance?
[1048 byte] By [
n_creepa] at [2007-11-27 7:05:54]
Invent a protocol, and then write a Java API that uses the protocol. If the protocol changes, change the API as well.Then users can just update the library holding the API. The actual interface in the API might not change, just the implementation of the protocol parts.
Thanks, but I want something stronger than that. So that if the game doesn't comply with the server, there would be a compilation error.
You can use enums for certain parts of the protocol, so that, for instance, they couldn't send a command that doesn't exist.
But really, there's only so much you can do. There will be things that wno't be known until runtime--distance to move, name of character to attack, etc.--so there's no way to test everything at compile time.
You have to be more specific about what you mean by "comply with the server."
jverda at 2007-7-12 18:57:08 >
If the game has to use the API, then it would get compile errors if it tried to use methods that didn't exist.But I think that using compile errors as a metric for correctness might be the wrong way to go.
> If the game has to use the API, then it would get
> compile errors if it tried to use methods that didn't
> exist.
>
> But I think that using compile errors as a metric for
> correctness might be the wrong way to go.
Seconded :).
Don't forget, that other people can write clients in C, Perl, and all sorts of other languages, and they aren't constrained by Java interfaces. Any program could try to connect to your server's game serving port.
So, if you depend too much on the clients being compliant to your protocol, somebody could write a simple client that just sends junk... it could crash your server sockets, or cause your app a lot of work, effectively performing a denial of service.
> So, if you depend too much on the clients being
> compliant to your protocol, somebody could write a
> simple client that just sends junk... it could crash
> your server sockets, or cause your app a lot of work,
> effectively performing a denial of service.
Somebody already has written such a client:
telnet that.game.host somePort
Trying www.xxx.yyy.zzz...
Connected to www.yahoo-ht3.akadns.net.
Escape character is '^]'.
afhhfladhfdhflkdhsf23079352h4';%$!#asfhalkshfalkh2352#$%#$%
jverda at 2007-7-12 18:57:08 >
My problem is not the clients, I'll make sure that they use the right protocol, and screen them otherwise.
The problem is the game used on the server, when I say "comply with the server" I mean that if the server sends it a certain command, the game should be able to translate it to its own command. And in case the protocol changes (e.g. another command is added) then the specifications for the game would change with it.
I know I'm being petty, but I want that a given game code could be known to work (in some way), without actually looking at the code, but just by compiling.
>If the game has to use the API, then it would get compile errors if it tried to use methods that didn't exist.
I don抰 understand this, isn抰 an API just a text/html file that doesn抰 have anything to do with compilation, how can it produce compile errors?
In any case I抦 assuming that everything is written in Java, so there is no need to consider other types of code.
> My problem is not the clients, I'll make sure that
> they use the right protocol, and screen them
> otherwise.
> The problem is the game used on the server, when I
> say "comply with the server" I mean that if the
> server sends it a certain command, the game should be
> able to translate it to its own command. And in case
> the protocol changes (e.g. another command is added)
> then the specifications for the game would change
> with it.
> I know I'm being petty, but I want that a given game
> code could be known to work (in some way), without
> actually looking at the code, but just by compiling.
So if you add a command, then you have to recompile and redeploy every client.
> >If the game has to use the API, then it would get
> compile errors if it tried to use methods that didn't
> exist.
>
> I don抰 understand this, isn抰 an API just a
> text/html file that doesn抰 have anything to do with
> compilation, how can it produce compile errors?
API = Application Programmer's Interface. It could be compile-time or runtime, but as used in a Java context, it usually refers to the public interfaces, classes, and methods--that is, it's a compile-time thing.
> In any case I抦 assuming that everything is written
> in Java, so there is no need to consider other types
> of code.
I can write a C, Perl, Python, Tcl, PHP, VB, shell, whatever client I want that talks your game's language, and your server wouldn't be able to tell the difference.
jverda at 2007-7-12 18:57:09 >
> I don抰 understand this, isn抰 an API just a
> text/html file that doesn抰 have anything to do with
> compilation, how can it produce compile errors?
No, you're confusing the API documentation with the API itself.
Write a protocol. Write a java library that implements the protocol and exposes it (exposes and/or hides it as needed) as the classes within the library. Thus, games, which are Applications, will having a Programming Interface (aka, API) to code to.
paulcw
I think that I understand what you are saying now.
I'll write a protocol and a game interface that uses that protocol. But if I'll change the protocol there would be no effect on the game interface, as it is independent, I抣l just have to rewrite the interface so that it'll fit again. But what I want is, that the game would be somehow aware of the currently used protocol.
> But what I want is, that the> game would be somehow aware of the currently> used protocol.Then you have to devise a way to update the game as the protocol changes. No magic will happen here.
jverda at 2007-7-12 18:57:09 >
I don't want the game to adjust itself "magically", I just want it give me complilation errors if the protocol changes
We're going in circles here. You really need to be more specific.
You'll get compilation errors if you add methods to an interface and don't add them to the classes that implement it.
Also if you make a method final that was being overridden.
Also if you change a method's signature, then the caller will give compilation errors.
But you can change the protocol without changing any method signatures, so there's no guarantee that changing the protocol will lead to compilation errors. Only if you change it in one of the ways described above. The word "protocol" however usually refers to the form of the data tranferred between client and server, not the methods called that send that data.
jverda at 2007-7-12 18:57:09 >
ok, I see the circles, but I think I've got the info I need, and I'll try to work with what I haveThanks for the help.
Cool. Good luck. And if you have more conrcrete questions once you get a little further along, go ahead and post them.
jverda at 2007-7-21 22:13:10 >
You may be abele to use polymorphism if you use OO protocols using RMI or CORBA which would enable your client/server to endure a lot of architectural changers whilst using the same protocol.
