I have a game that is going to use a server to handle multiplayer. The game is turn based but with turns taken simultaneously. Initially I thought I should use a separate thread for each user but I realised that I could simplify by just tracking each user based on their IP. Is this possible or would it lead to issues with dynamic IPs or people playing from the same location?
This could lead to problems because some ISPs, such as AOL, aggregate traffic for multiple users through a single IP. If you track both the client's IP and the client's port number, though, that should be sufficient.
Related
I am making a game of Bingo. For that I will be connecting two mobiles via wifi- hotspot and the grid should be shared to both clients, that is both mobiles should see the grid. How can i pass the grid two both clients? Also, how to pass numbers in between client and server? Via object or other thing and how? Also how to exactly implement client server application making 2 java files n android? PS: we are not implementing a chat application.
Bingo XML file: https://github.com/TanishaShrotriya/SDL/blob/master/activity_main_bingo.xml
Java File:https://github.com/TanishaShrotriya/SDL/blob/master/MainActivity_bingo.java
You have a few options. First you need to determine which architecture works for you.
Client/Server (AWS Instance with APIs, and Firebase with PUSH)
---This will enable the devices to get current came status on open, and push changes to their board on confirming their space was called/filled.
---This will enable other devices in that "room" a name given to a virtual shared space for a game. To receive PUSH notification of changed data to display.
Next you need to decide if the server will maintain the full state of each user or just the current called values for comparisons.
If you decide that you do not want to write APIs and setup a Server for PUSH, you can do an ad-hoc wi-fi or even a BLE based communication among everyone in the area. However, this will require significantly more understanding of how to pass bytes, handle network issues, latencies, and communicating from device to device.
If you choose to do the ad-hoc wifi as you mentioned you would have to maintain a ton of connections like a mesh network. A better option would be to have all devices join the same wifi network so that they have access to each other, but aren't necessarily keeping track of mesh networking.
However, even if you are on the same wifi knowing who to send the information to can be difficult without a server to retain routes and IPs of current players. So you may have to create a host so that it can listen for enrolled players. The host device would need to retain routes to all other devices so that it can send the info to each IP address when a change occurs.
I still highly recommend going the client/server route of APIs and PUSH it will be far more reliable.
Now as far as how to pass the data, you could of course screenshot via code and send images, but that is wasteful. I would recommend having a matrix that keeps track of the values covered and simply send a JSON snippet of the card_id, the player_id, and the json of covered blocks to the server that can then push changes back to all players in the "virtual room". This allows them to see how their fellow competitors are doing.
So I would have to ask for more details about what your goal is to help any further, but that is my recommendation, because ad-hoc wifi or bluetooth is doable, but on a mesh scale size you will have a giant headache on your hands. The host scenario device with all on same wifi would be my second direction if you are really anti-server and APIs, which the only reason I could see you avoiding that is if you wanted to play off wifi that doesn't have internet or if you don't want to pay the $30/month for traffic while it is small.
Let me know if that helps or if you want to provide additional clarity.
I'm creating on online real-time multiplayer mobile game using Kryonet (a Java TCP/UDP networking library) that I'm planning to host on AWS.
The architecture is as follows: clients connect to a central login/account server that allows them to login and view their stats etc. This bit is easy, as it'll basically just be a REST API, and can be scaled in a pretty standard way (like you would any webapp).
However, the more interesting bit is when players actually play a match. For this, I plan to have a separate pool of "match" servers (EC2s). The login/account server will pair two players, then send the client the address of a particular match server. The players will then join that match server, which will host their match (perhaps lasting 5-10 minutes). The match server needs to be sticky as it will be running a real-time instance of the game, and will be sending/receiving UDP packets in real time. Each match server will probably be able to host a few hundred matches.
My question is about how I should go about scaling these match servers. I suppose I will have them auto-register with the central server at start-up, and send some type of keep alive. I could build this all myself; however, I'm wondering if AWS has tools/services that can do this all for me.
Okay, I've done a little more reading of the AWS documentation. It seems that I can probably achieve this as follows:
Each time two players are paired up, they are added to a queue. They are taken off the queue when a spot is free on one of the match-playing servers. When the size of this queue exceeds some threshold, then the number of EC2s is scaled. This can be done with basically all in AWS config: http://docs.aws.amazon.com/autoscaling/latest/userguide/as-using-sqs-queue.html
The tricky bit is then scaling down instances. Unlike a normal REST API, you can't just turn a server off. The server needs to finish all its current games. It seems that AWS has this covered too with lifecycle hooks.
For a college assignment I'm building a networked Java application using sockets*. My architecture must be scalable so I would like to have multiple servers available for my clients to communicate with.
My question is, how can a client know about all available servers? My first thought is for the clients to keep a (hardcoded) list of server IP addresses and select from the list. What is best practice in this case?
*We cannot use RMI.
Let's imagine your network provider's costs got too high, and you decided to switch. Boom go your IP addresses. I would suggest the judicious use of DNS, especially round-robin DNS.
Using a central tracker could seem like a good idea, but it itself must be scalable, akin to Google App Engine, or it will become a chokepoint.
Simply create multiple A-records for a given name, and your clients will randomly select one when resolving.
If you are unable to use DNS an IP list may be beneficial--with one change. All of the servers circulate updated copies of the list and if a server cannot be reached, another is tried until a connection is made(and the list likewise updated). When the list is found to differ from the existing one the client's list is updated.
You can use RMI stuffs, making primary and secondary servers.
Secondary server may be continuously polling primary, when primary goes down, secondary can register on naming services to take on. When primary comes back, it will register back making secondary go down... like that.
Regarding client to know server, client can ask servers using RMI for identity.
Is that possible to create a LAN messenger ( with user verification ) without a central server..?
I want to use JAVA for the messenger and with the facility of video conference. The main problem I faced is that how/where will I save user's data.
If by without a server you mean without any central computer then yes you can (with any computer listening and dynamically taking server role or something like everyone is server and client simultanously). It could work like p2p.
You could also use brodcast messages to achieve that. User authentication is the issue, but you can store user id's and hashed passwords on each machine (and syncronizing it as often as possible)
I've implemented it some years ago: basically I do a listen on an UDP port for each time a user open his client (I've done that by a separate thread) that accept a particular type of pkt that define username, user ip and so on...
In that way i have a kind of p2p mechanism.
User auth is achived by store user's password in a crypted way (sha5 and so on..)
You can save data locally on each machine.
You can try to use some DHT as an underlying system. It should be able handle all communications between the network nodes as well as distributed data storage.
A new node can join if it knows at least one node that is already in the network. And a node can send a message to some other node if it knows its ip or dns name.
P.S.: If you're interested in the idea you may took a look on Open Chord. Its only drawback is that there's no persistence, i.e. it doesn't store the data anywhere except the RAM, so you'll need to add your own persistence.
P.P.S.: you may event create new skype but without a central server at all
I would like to connect two phones together for somewhat of a P2P style connection and naturally to do so, I need the phones to be able to communicate their IP addresses to each other. I've been playing around with a lot of ideas on how to do this and one thing I realized is that a phone number is a unique identifier for a phone and thus I was wondering if it could be used to get IP addresses.
I think I could transmit certain messages over SMS that would be encrypted, look god-awful, and then get deleted, but that would be a bit of a hack and a terribly messy way to do things. I'm still mostly planning for this area of my project and would be open to suggestions.
Any help would be appreciated, thank you ahead of time! :0)
You could use a dynamic DNS service, using the phone number as the hostname. In other words, you would simply do a DNS lookup of e.g. 4255551212.dyndns.com and you'd get the last known IP address of the given phone number.
The dynamic DNS service was invented to let people on dial-up (or with frequently-changing IP addresses) run servers on their computers with host names that did not change. The way it works is, there's a client on the computer that periodically reports its IP address to a server, which puts it in a zone file on a DNS server under the specified host name. The DNS record has a short time-to-live (e.g. a minute) so that stale address information is not cached.
There's a dynamic DNS client for Android, look for DynDNS in the market and try it out.
You could run your own dynamic DNS server or use an existing one (there are many, some free). If you do do this, I would suggest running your own; then you could include some kind of authentication to prevent the privacy issue I mention in a comment.
A problem you will find is that 3G/cell connectivity gives no IP address. Also, if your phone is behind a router, you would have to port-forward on the router to get a P2P connection (without a central server being involved).
That said, if you want the external IP address, it seems that hitting http://www.whatsmyip.org/ is the best way to go.
Note: I do not know much about the dynamic DNS option suggested by kindall.
I am pretty sure you cannot directly do so. I think you need both phones to transfer phonenumber and IP to your own server and tie everything together through there. Privacy issues will creep up whatever solution you choose though, when phonenumber is involved.
Also I don't know whether you actually can connect from phone A to B directly even IF you have the IP number? But I am not an App Dev yet, so you probably know better if you can set up an end-point / open socket like thing at phone B.
you can use a site like www.whatsmyip.org to get you ip address
it is possible that your phone shares its ip address with other clients
you could also use a vpn or depending on your application a mediator server using soup or xmpp