Multiplayer game in Java. What's the best solution? - java

I'm writing a multiplayer/multiroom game (Hearts) in java, using RMI and a centralized server.
But there's a problem: RMI Callbacks will not work beacause clients are Natted and Firewalled. I basically need the server to push data updates to clients, possibly without using polling and without using sockets (I would code at an higher level)
In your opinion, what's the best solution for realizing this kind of architecture? Is an ajax application the only solution?

You say that you don't want polling, but AJAX is exactly that. You can look at Comet but it's hard to escape polling anyway (e.g. Comet itself uses polling underneath).

You could use a peer to peer framework such as JXTA.

I can suggest two main techniques.
The server has a method getUpdates, callable by clients. The method returns the control to the client when there is an update to show.
When Clients perform the registration, they give the server a callback remote object
Since this object is not registered in any rmi registry, there should no be any issue with natted clients.

I'm not sure how(if) ajax works for a non-browser-based app. You could just maintain your own pool of SocketConnections open for the duration of the application with a Thread per connection.
If you need to scale to a lot of concurrent connections, look to a non-blocking I/O framework like Apache Mina or Netty (related SO post: Netty vs Apache MINA).

Related

Is this an appropriate use of websocket programming?

I am incredibly new to the topic of websockets and am trying to figure out the correct way to handle the communication between a device and a server.
Here is my scenario: I have a thermostat (very similar to the Nest) that needs to communicate with a web server. Every time you change the temperature on the thermostat, I need to send data to the web server to update it's "current stats" in the database. Easy, I can do that.
The part that I am confused about, and think websockets might be a use-case is when the user changes the temperature from the web interface. The thermostat has to pull in that information from the server to see "Oh, okay you want it to be 66 degrees."
I've thought of having the thermostat long-polling the server every 2-5 seconds to see what the "current stats" are in the database to change the temperature, but that seems like overkill.
Is there a way to open a connection between the thermostat and the server to listen for messages?
I began down the road of reading about websockets, however, I believe it is unfortunately browser-based only.
As I'm fairly new to the game with regards to these types of connections, if anyone could point me in the right direction regarding protocols, communication, etc. I would greatly appreciate it!
Tech Specs
Server is written in Ruby on Rails
Thermostat is written in Java
Websockets can be used between any two programs which need to communicate, they are certainly not restricted to the browser. That said, should you be using websockets is a different question. one thing to think about is that websockets involves a persistent connection. this may not scale (if you have lots of devices) and it may also be overkill. if you are expecting the temperature to be changed once a day, having a persistent connection for the entire day is an enormous waste of resources. websockets are typically used when communication needs to be "fast" and relatively frequent. unless you really need instantaneous updates in the thermostat, i would just have it ping the server every few minutes for updates.
Side note, websockets is fairly new, so any libraries you end up using may be a bit on the immature side.
We prototyped some java to java websockets a while not too long ago. We used the ning async library on the client side and the atmosphere library (built on netty) on the server side.
WebSockets is just a specification for tunneling something similar to TCP sockets over HTTP; it's not confined to the browser, and client libraries are available for most common languages.
This sounds like a reasonable use case for a long-running connection, but I would generally prefer a raw TCP connection to a WebSockets connection unless you have a specific restriction in mind (e.g., most home Internet connections have no problem with connecting to a server at an arbitrary port).

Connections between controller and remote worker machines

I need to develop a platform in Java to download tweets from Twitter (that was obvious). The idea is to have various computers downloading from the streaming API and a main controller to send tasks (keywords to download and other data) to each fetcher. My problem is related with the connection between this programs. Which is the best way to do this? Actually I'm using RMI to send commands like "stop", "start", "setTask" from the Controller (client) to each fetcher (servers) and a SSLSocket to make a quick validation, but I'm not sure if this is a good idea. I could use TCP sockets but maybe it's not a good idea to have permanent connections. What do you think? Is it a good idea to keep using RMI or should I take another point of view?
Thank you ;)
I propose you to use queue (and any queue protocol).
ActiveMQ, RabbitMQ, QPID, or one of many other tool.
I use ActiveMQ in prod and fine with it, but for very highroad RabbitMQ will be better.
you receive easy scaling for any count of workers and easiest way to share/split tasks between workers.
Also please look on ActiveMQ or RabbitMQ or ZeroMQ or

Java communication between 2 applications

Considering application_A on a machine_1 needs information about machine_2, provided by application_B (which is located on machine_2) and that both machines are in the same network, what would you guys suggest to be the easiest way of implementing the communication between the 2? (I was thinking simple socket connection).
Note: the information required is something in the lines of a few bytes, so nothing big.
You can either use socket based communication or Java RMI.
I would recommend Java RMI as its easier and saves you from handling raw socket communication.
If you are familiar with Spring framework, then writing RMI application in spring is very easy. Check Exposing services using RMI (Heading 17.2)
There are different ways to implement this but they all come down to one thing: communication over sockets.
If the information is only some bytes, implementing the sockets themselves is probably your best bet, if things start to get bigger, you might want to look into some middleware.
You can run a server program on Machine2 using ServerSocket and a client program in Machine1 can request for info.
You can try web services. JAX-RS would be the simplest.

Managing multiple socket connections in a java server application

In our new project we need to implement a server application. This server gets connection requests of 50,000(+) clients. Problem is these connections have to remain open and have to be managed somewhere. The application should work like a telephone exchange. So it can get requests of connected clients and connect them to other (maybe several) clients only if they are also connected. A proprietary protocol is used. My questions are:
How (and where) to manage the open sockets? Should I put them in a HashMap or something? This sounds curious to me. But I don't have experiences with so many open connections.
Are there any frameworks available which support this connection requirements?
Thank you for your help!
How (and where) to manage the open sockets? Should I put them in a HashMap or something?
Typically each socket will be managed by a thread that will be responsible for reading and writing to the socket. You would also have a master thread that is responsible for receiving all connection requests at a predefined network interface & port (using the ServerSocket API class), which may then hand off the actual processing work to the worker/slave threads. In this case, you ought to be looking at a thread pool for the worker threads, because creating 50k threads will most likely overwhelm your OS and the hardware.
Also, if you are indeed managing 50k concurrent sockets, using NIO API (java.nio.*) over the plain IO API of Java is highly recommended, although I haven't seen too many projects requiring more than 2-5k concurrent connections. There are atleast two known NIO based frameworks in the Java world - Apache MINA and JBoss Netty. I would however recommend reading the well written NIO tutorial, before heading onto use the NIO API or the NIO frameworks.

Message to a client from the server

I have to design a client/server system emulated on a website running Ruby on Rails that should work like this:
a page is requested by a web browser and once it's opened the server can push messages to it
I know this is not possible "naturally" but I was thinking of a sort of "java applet" that is running on that page, listening on a port for messages to be sent by the hosting server. This should be done opening a sort of a socket that listens on some port where the server can connect to send its messages.
Can this be done? Do I have to develop a java server thread or can I simply address the client applet via it's ip address and port and use any web service connection from the server?
thanks,
Luca
Comet is definately what you want. Depending on your needs, you can host your own comet server, or use a SaaS solution, such as WebSync On-Demand (disclaimer: I work there). Using the SaaS stuff, you get server-push capabilities without having to actually run your own comet server.
The easiest way to do that is to use Javascript to emulate the push mechanism. Polling in regular intervals using AJAX is sufficient in most cases. Have also a look at Comet.
An alternative to using a java applet may be to use a combination of javascript and an approach known as Comet. In a nutshell, Comet is a way to enable server push over HTTP. I'm not really a ruby on rails guy, but a quick google search for ruby on rails and comet nets a fair amount of useful information.
have you looked at juggernaut
If you want go the applet route, you need to make the connection from applet to the same server where the web page is served. The applet can't listen. Once the TCP connection is established, it's a 2-way channel, you can pull or push as long as your protocol allows it. This is how it's done with most Applet-based chat clients.
More and more people are simply using long polling in Javascript. It's pretty involved to get a reliable long polling system running, I would suggest you to use a framework. For example,
http://cometdproject.dojotoolkit.org/

Categories