I am currently developing a game, and would like to separate the login server from the game server. While I am experienced with client-server networking, I have never done any work communicating between servers. What are some standard or accepted methods of accomplishing this? My current topology(?) is to have the game client connect to the game server, handle all logging in and authentication, and then start processing game data/packets. What I would like to do, is split the login server and game server into separate entities, such that the client will initially connect to the login server, after proper authentication has been reached, send the client over to the game server and start processing game data.
What would be an acceptable way of handling this?
EDIT: It seems the intention of the question may be unclear. My question is, is there some sort of functionality that would allow server-server communication, OTHER than creating the login server as a client to the game server?
No, There is not. One of the two parties always needs to be listening for connections while the other end connects to it.
Related
I'm trying to make a simple tic-tac-toe online multiplayer game in Play Framework in Java (but I can read Scala too) and I need to notify one client when the other client has made a move - has inserted a new database entry. The frontend uses HTML and JS.
Do I use WebSockets or Server Sent Events for this and how?
Thanks a lot guys, the Play framework documentation for both is still not updated and it's a well known issue https://github.com/playframework/playframework/issues/5057 as well.
EDIT: The main question here is really how to do it?
Personally for a game I would establish a Web Socket connection over a SSE.
Fast data transfers
A two way stream of message, where SSE would require the client to send ajax requests and listen to SSE where WS all sits in one place.
Allows you to establish when one of the 2 clients looses connections, thus pausing or notifying the other player.
Resource you can use to Implement this:
https://www.playframework.com/documentation/2.5.x/ScalaWebSockets
Edit: Latest version https://www.playframework.com/documentation/2.6.x/ScalaWebSockets
So im creating this game using pygame, and i have to put it up on a website, but it has to run server-side since the game is gonna be using a database locally, and the client will be able to enter a web page and click on a button and the game is gonna run, i cant make the game run completely client side because then the game wont be able to connect to my local database
Any ideas?
The way I see it you have two options:
If network connection is intermittent (not so frequent), you can use javascript (AJAX specifically) to make HTTP calls to the server whenever you need to access your database.
If you are expecting frequent (continuous) requests (i.e. multiplayer games), you would need to keep a connection alive using either
Persistent HTTP request
TCP Socket
Websocket : You probably want to use this if you want cross-browser support.
Let me know if you have any other questions regarding the options above.
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
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).
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