This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm an intermediate Java programmer, and I'm trying to create a fairly simple (not graphics-intensive) multi-party card game. The whole gaming environment is new to me, so please forgive the dumb questions.
My idea was to use an MVC model. The user interface would be via a JApplet, that communicated back to a server-side controller. I'm having a problem with that communication.
I originally looked into JSP and Servlets, but they only handle String data. I could live with that, but I couldn't see how to pass the data into the JApplet, in the interactive way I needed.
Then I tried Sockets, which work, but it is such a low-level interface that to pass complex data or objects across it seemed more trouble than it was worth.
I've been working on RMI tutorials for the last few days, which looks good. RMI allows me to do remote method invocations, and pass objects back and forth. But now I'm stuck, at the server implementation/security implementation point, hence my questions.
A. Is RMI a reasonable method for passing data back and forth to a server-side controller? Is there something better?
B. Does the Apache Tomcat server support RMI, or should I try to write my own server?
C. Can anyone recommend a good tutorial or book on this subject?
Using RMI for client/server game design is an interesting concept. I'm not sure I've seen this method used before in a game. I would imagine that it would be slower than just pure sockets. But for a card game or something it probably wouldn't matter.
You could have issues using sockets with an applet because of the security sandbox it is written in. Maybe if you told us a bit more about the "complex objects and data" you are having to send and receive we could help point you in the right direction.
As far as what is normally done, sockets. Typically you would write a client and a server. The server runs and listens for your client and they communicate back and forth. This you know. Typically you would create a protocal by which your server and client communicate which is usually just a series of characters that you decode to mean something useful to your application. Yes, this is low level, but it's a good way to do it. [ July 27, 2005: Message edited by: Gregg Bolinger ]
What you could try is just opening a URLConnection or just plain Socket* back to the server, getting the associated input and output streams, and using those to instantiate an ObjectInputStream and an ObjectOutputStream. If you also use ObjectXxxputStreams on the server, then you should be able to pass Serializable objects back and forth without any trouble.
Or is there a application reason to graduate from merely Seialized objects up to RMI?
* The decision between a URLConnection and a Socket depends on how you implemented the server. If you wrote the server from the ground up to listen on a port, accept connections, and handle all the protocol then use a Socket. If the server is part of a web/application server, such as Tomcat, and the underlying protocol is HTTP then use a URLConnection. This isn't a hard and fast rule, but it's the rule of thumb I use.
Joined: Jul 25, 2005
Thanks for the feedback!
No, I had no particular reason to use RMI, except that I thought it would be the easiest way to pass custom objects from the game code running on the server to the JApplet GUI. If I can do the same thing with a socket or URL connection that is fine with me. And if RMI slows performance, I don't want to use it.
One more elementary question, if you don't mind - I'm a bit confused about the JApplet code. Assume the JApplet html file, and the JApplet class file, is hosted on the webspace provided by my ISP.
Then, the JApplet code, when it tries to make a connection to my PC (to get to the game logic code running on my machine), has to have a hardcoded address, right? Something like
The problem with this is that I don't have a permanent IP address for my machine. I get a new IP address from my ISP every time I start up. So wouldn't I have to recode that hardcoded IP address and redeploy the compiled applet code to my ISP webspace every time? Or am I missing something obvious?
Maybe I want to keep the JApplet class file on my own machine, and then use something like:
I'm sure this is a problem that real game programmers have solved a long time ago, but I'm new at this.
I think the easiest solution would be to register a domain. :-) Otherwise, if you want to serve from your home machine, the cheapest solution would be register with a dynamic dns service and then just use
to get an InetAddress for use when creating your Socket, i.e.
btw, dyndns.org is a site offering the dynamic dns service for free