Which is the best way to connect 2 android phones in the internet with a Java Server?
I'm making an game form android. At this moment i have the single player working. But now i have two use an Java server to play online games.
Which is the best way to communicate with 2 phones ?
Most difficult action is send information of client1 to the Server and Server redirect this information to client 2.
Anyone can help me?
Regards
You can use either SOAP or REST, using Jax-RS (rest) or Java-WS (SOAP).
http://www.oracle.com/technetwork/java/index-jsp-137004.html
http://docs.oracle.com/javaee/6/tutorial/doc/giepu.html
Here is one way, assuming your game has some turn based interface, and you want to do is have a create game/join game or a create game with user style interface.
When the game starts, connect to the server using one of
the above techniques (soap/rest) to let the server know you are
there.
Then have one client say create a new game. This will tell the
server to create the game.
The other client will tell the server to list games. Then on
the client, choose a game to join. Then tell the server of the game
choice, so that it knows to add you.
The phone that started the game, should poll the server to see if
another user joined the game. Eventually some will join. (there are
other ways to handle this, but polling is very easy to do)
Have all players in the game poll to find out if the game started, then
go, once they have all joined.
There sure isn't a best way to do that. There are some techniques.
But what I would do is to create a long, unclosed http request from both of the clients to the server and then when something happens the clients get responses from the server. This is called Comet, but I never implemented that by myself. There sure is an Android implementation (or just a Java implementation).
Related
I am trying to implement a 2 player game. Where the 2 clients communicate with the server to play the game and server decides which player has won the game. I am using distributed approach using TCP connection.
As part of my implementation I will have to see that even though one client is right beside the server and other client in located miles away, both the client should get the response from the server at almost same time. In one part of my game the server displays a prompt box to both the clients and the client who clicks the box will be the winner. For the server to decide this, I want to use cristains algorithm for clock synchronization.
My problem is I have an idea what to do but finding it difficult to write the code.
This might help, it will allow players to subscribe to a topic and post/get messages to and from that topic, I've used this for a 2 player game and it worked fine
http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm
I'm developing a multiplayer turn based strategy game in Java (both client and server). I don't have much experience in networked games but I have done small things like a multiclient chat and 2 player tic tac toe with sockets. I'm not looking for someone to code this for me but just give me some guidance.
The game goes through multiple stages: first a user connects and logins. After he is given the option to host/join a game. After he joins a game or someone joins his game, the client moves on to the game stage. The game is 1v1 and only needs to send data back and forth every 5 seconds (if that's important?). I just need some guidance on how you could design a client/server to move through these "stages".
This is how I'm currently thinking of implementing it:
When a connection is made the connection will have a corresponding variable that describes state on the server. For example: 0 is before login, 1 is after login, 2 is hosting, etc...
Whenever the client sends data to the server it checks for the state and deals with it accordingly. Like before login if data is sent, the server will assume it's login details and if they're valid it changes the variable to 1 and tells the client to advance.
Is there a better way to do this?
Since is Full Java + Client-Server + Game:
I recommend you to forget using straight sockets.
In my opinion Java RMI is your best bet.
Why?:
Easier than sockets once you have it learned.
You can call remote methods straight from your java client/server.
You can use callbacks. (i.e. Server testing that the clients are still connected)
There are probably even more reasons...
Essentially how you described it is how it is commonly done. Simply have a server listening for client connections, and then deal with client connections in its own thread as they come up. Then send messages back and forth to confirm state (logged in vs. logged out, joining game, etc.) and messages while in game for player moves. Either a TCP or UDP socket will work in the short term, however eventually you will probably switch to a primarily UDP based system as the messages sent between server and client will be fairly small and latency could be key depending on the game type.
Consider sending/recieving messages via JSON (http://wiki.fasterxml.com/JacksonHome is a fairly popular Java parser last I checked).
Additionally, you'll need several data structures on the server side to efficiently manage clients and their states. For example, you could have an integer id for each client and a Map<Integer, Client> that you would use to store all currently connected logged in users, where Client is some object that stores the current state of that user.
Hopefully this gives you some ideas on where to start.
You can use Mina or Netty as Nio socket framework. Using Java both in server and client makes it easier to design message protocol. When one client moves, you send a moving message to the server, and then server pushes back a message to both clients. Both clients move together when receiving the message. Thus two clients move synchronously if avoiding network delay.
You can take a look at the open-source game framework written in java.
java game server engine
I currently have a multiplayer card game developed and working in Java and it is working in the console. The game is similar in format to Bridge and Spades, minus the bidding process. It is a four-player game, and players take turns playing a card.
I am currently working to convert this to a browser-based webapp, and am adding Spring MVC, and using HTML, JavaScript, and AJAX for the UI and communication with the backend. I have a good idea of the approach I want to take on getting this to work single-player against the AI, allowing the user to play their card and using an AJAX call to get the next three plays from the server.
However, I'm wondering what kind of approach I would need to take for this to be multiplayer. I have seen some references to "Socket-programming," which I am unfamiliar with, but those seem to revolve around Java applets, instead of a browser-based app.
Basically, I am looking for a way to ensure that when a user starts a game and someone else joins, how do I ensure that they are connected to the same game, and are able to see each others' plays? I am asking this now before I have the UI fully developed for single-player, because I want to avoid a complete redesign to support multiplayer functionality.
Since you are creating a multiplayer game, you will need to have at least one server for your client(s) to connect to. Since you want to make this browser based, you will most likely need your own server (rather than having one of the clients be a server). When a user joins a game, it is logged on the server where that user is. When a player performs an action, the server processes the action, then sends a notification to each of the other clients connected to that room. At that point the clients UI updates.
In the past, you could not do this with pure HTML / JavaScript as you cannot open a socket. Which means, the server could not notify the clients. However in HTML5 you should be able to use WebSockets to achieve what you are doing with a server in the middle. The WebSocket API
However, if you don't want to use HTML5 WebSockets, there is another technique that imitates Sockets in JavaScript. That is, the server can talk to the clients. This technique is called long polling. The client sends a request to the server asking for an update, if there is no update available, the server holds the request until an update is available and sends it back to the client at which point they make another update request. Simple Long Polling Example
Another option, if you are very familiar with Java you may wish to check out Google Web Toolkit. GWT is a subset of Java that is compiled into HTML and JavaScript for the front end and if needed creates a Server Side java executable that you can use with TomCat or another web service. In this option, you have a few libraries that allow you to write socket-style code that will be compiled into Long Polling JavaScript.
Best of luck!
I have experience developing in android and using REST services, but now I'd like to implement an online game for android. For example a tic-tac-toe for multiplayer, where a user can invite to other to play a game and each one receive the actions of the other in real time.
Using REST for this kind of apps would require constants surveys to the server for updates and its a bad idea.Isn't it?
My question is what are the typical aproaches for this kind of "permanent" connections. I just need some hints about the technologies and protocols in client and server for start searching and read :D
Thanks
You can use sockets directly but for a game like tic-tac-toe, it shouldn't be THAT chatty, using REST would be ok.
I'm programming an Android multi-player game, which basically consist of a server where the clients connect and exchange messages. When the player connects to a server, a player list is return to him/her. A player can then select a user to challenge - of course he must select a player from the player list, which only contains connected users.
When a player1 challenges player2, a message needs to be transmitted from player1 to the server, which in turn must send a message to the player2, notifying him about the challenge. The player2 can then accept/decline the challenge.
I can use the following techniques to make this happen:
Use custom server/client with Java socket programming. The server basically accepts a connection from the client, spawning a new thread for each connected client. The problem with this are:
There needs to be a persistent connection open from client to server wasting battery life of the android phone. This is not really big limitation since the battery isn't consumed that much.
When I'll want to develop another game I'll have to rewrite the client/server code from the scratch - also choosing another port to listen for incoming connections - the whole concept gets rather difficult to maintain.
I'm also worried if this is the way to do it. Spawning another thread for each clients sound quite a lot if thousands clients are connecting at the same time. But I'm guessing the PC games do it like this. Not sure about android.
Use Java REST jersey to build the client-server on top of HTTP. This would be a perfect solution if the server could easily send notifications to clients. There are actually multiple design decisions here:
the client pulls the server for any new data/notifications every few seconds - this is really bad, since we're stuck with non responsiveness, delay, etc.
the client can send a waiting request to server, so the client receives the response only after some data becomes available. This is better, but can still produce a delay when two notifications one after another need to be sent to the user. The first notification is sent instantly, since the client already has a connection open, waiting for data to receive. But we would have to wait for the client to initiate another long http request to receive the second notification. The problem gets bigger as there are multiple notifications that need to be send in a row to a specific client.
the client can initiate a http streaming, where the communication is left open when the request is handled, so the server can also send multiple messages to client whenever it wishes. The problem here is that I don't know how well this works on Android. I've looked at several implementations:
Java jersey + atmosphere: didn't succeed in actually making it work. This seems the most promising, but I don't want to spend too much time on it, since I'm not even sure if it does what I want.
Deacon: seems pretty neat, but after seen the video tutorial on their official web page, I'm not sure that it can do what I need. When a player1 challenges player2, can it send a notification to player2 letting it know about the match request?
I would be glad to know how other multi-player games handle the network communications, if the two players are playing the game over the network.
I'm also open to a totally new suggestion how to achieve what I want. I can pretty much code anything, so don't hesitate to let me know of some more difficult way to achieve the network communication.
Let me also mention that I'll be glad to implement a totally specific method to work in my case, so it can be anything that will do the job done, but I'm also looking at more general way for communication between clients and server. So that I can program an interface/whatever and reuse the code in other android games, android applications.
I hope I presented the problem allright and that I'll receive some valuable answers.
Thank you
You should take a look at XMPP. It's a protocol (originally created for chat programs) that allows sending of xml data between users.
It has a separated client-server relationship, so that you can focus on developing a client application fit for phones, and a different server depending on your needs.
There are loads of information available on the protocol (I should know, I wrote a thesis about using the protocol in game applications), but you can start by looking it up on wikipedia to see if it is what you want.
aSmack is a library for creating android xmpp-clients. It takes some tweaking to set it up and get everything to work, but once you do, it's neat.
EDIT: relating to the answer suggesting using the C2DM:
from the c2dm docs "Sending large numbers of C2DM messages":
Are you sending C2DM messages too frequently? If you need to communicate with your application frequently over a short period of
time, C2DM is probably not the best solution. Instead, consider
implemeting XMPP or your own protocol to exchange messages, and use
C2DM only to send the initial notification.
It sounds like Android Cloud-to-Device-Messaging might be what you need
Push notifications without the app having to keep a connection open
I would vote in favor of some message passing technique - like activeMQ, rabbitMQ, zeroMQ eor something like it. On the server side you may stick with java , or javascript ( like
node.js ) - such solution would provide most performance and minimal latencies.
If latency is not that critical, you may as well use REST calls with JSON