I'm working on a multiplayer iPhone application that allows up to 6 users to connect and play in "real time." I've been looking at hosted and non-hosted socket servers (SmartFox, ElectroServer, Photon/Neutron, ProjectDarkstar) and I'm wondering if anyone has any recommendations for services or implementation? Anyone have any idea of what a game like Zynga's Live Poker uses for this type of functionality or what kind of hardware you might need?
Some sub-questions:
The game is turn-based. Would it make more sense to use AMF and poll a server or should I go for the socket-based route? My current concern is concurrent connection limits and hosting costs.
Is it possible to "broadcast" a device as a socket server? i.e. once I get all my players connected, could I allocate one of the 6 devices to be a socket server and push all communication through that device? Would that be crazy? That would get around concurrency issues and I'd only need to rely on the socket server service as a lobby for the initial connection. The allocated user would stay connected to facilitate game to server communication.
1.
It's much easier to use polling, and since the game is turn based you could poll at a relatively slow rate (perhaps a couple of seconds), which means less battery drain. That said, using sockets or persistent HTTP connections would be a slicker way of doing it (and much more work). These two questions might be of interest:
How do I create a chat server that is not driven by polling?
COMET (server push to client) on iPhone
I don't know why you would use AMF. Why not JSON? Or maybe HessianKit?
2.
It makes a lot of sense to designate one of the devices as a server. Having a completely decentralized network of game clients that need to synchronize is a very hard task. Again, since your game is turn based, which doesn't require perfect real-time synchronization, you don't have to worry that having centralized state will introduce more latency.
If you intend for users to play over a local network, you should consider using GameKit.
Related
i'm having hard time to find an answer regarding to develop real-time multiplayer with node.js. Currently i have a small team and wanted to build a realtime multiplayer boardgame(turn base) which will be cross-platform between ios and android. Since we are out of budget to subscribe Photon or Smartfox as the multiplayer server, we suggest to setup our own node.js server. But since we are so new to the real-time multiplayer game development, we are still struggle with the decision whether node.js is the right server for our realtime multiplayer board game.
We are aware that some of the developers mentioned that the speed of node.js is slower since it is using TCP instead of UDP, but we do read some post/tutorial that using node.js as the multiplayer server.
I wanted to know if anyone here use node.js as the server when develop real-time multiplayer game?
Node can do TCP or UDP and can be a great choice as a real time server, however there are some pros and cons (as always):
Pros:
Node is easy to develop for due to strong community and plethora of modules and examples
By default, your server will be async and will be able to handle a lot of concurrent connections without you really having to do anything
Cons:
By default node will run in just one logical thread for all connections, so if you do any compute in response to a message, you are blocking all other responses from your server. So node is best suited to low compute but high I/O servers
If your realtime server creates and destroys a lot of objects then you can trigger the garbage collector which will effectively pause your server. This usually completes quickly and when it finishes all received requests will be serviced, but it does mean you get the ocasional spike in latency
So, if your server is low compute, and can handle the occasional minor latency spike, node js is a fine choice.
I would suggest designing the server so you can run multiple instances at once, as if you do hit processing bottlenecks you can simply scale horizontally by adding more server instances.
If continuous low latency is a requirement, you could also investigate golang, although it is harder to write for.
We are planning a real-time network game application for mobiles.
After some researches and studying, we decided to use a TCP connection between the server and the clients (mobile devices) by implementing Socket.
As we are writing the protocols, we came across the following question: where should we implement the computation? In the user's device or in the server?
For example, imagine a short game between 5 players which does not require communication until the game ends (hitting the screen as fast as you can or something like that).
At the end of the round, the clients send their score to the server, and the application should display the loser or the winner.
Where should the computation take place? Should the server collect all of the scores, compute the maximum and the minimum and send back the loser and winner? Or should the server send back all the scores to the players, in which their devices will compute the results?
What are the pros and cons of each strategy?
A couple of things here:
1) Do not use a persistent socket for mobile applications. Connectivity is too spotty.
2) Use a higher level protocol, like HTTP. You have no need to use such a low-level protocol. By doing so you are going to end up doing far more work than you need to. Think about if you want to build this into a web-based game, or implement on a device that doesn't allow you to use raw sockets.
HTTP is nice because it is firewall friendly, most firewalls already let HTTP on standard ports through. This is why it is so popular these days.
3) You should think very skeptically about the devices. In general you should trust clients as little as possible. You can do processing on the client, but it should be related to rendering. Generally assuming that your client is malicious is a good approach to n-tier architecture applications. Especially with games.
I have an Arduino based device interfaced to a 3G modem which I use to record data from several sensors in a remote environment. I would like to be able to send commands and stream some data from the device every now and then back to my standard network connected PC. If the remote device was connected to a WIFI or other local area network this would be relatively straightforward, but as the device connects over 3G this means that it is behind the 3G carriers NAT and so establishing a connection to the device becomes difficult.
The device can, of course, open a TCP connection to my host PC any time it wishes, the problem is telling the device when i want it to do so. I need some way of getting some kind of message to the device to notify it that I would like it to initiate a connection to my PC.
I've been reading up on NAT traversal techniques that app developers use to initiate P2P comms between 2 devices both behind NATs such as UDP and TCP 'hole punching' but this method seems rather too complex for my arduino system. Another general idea is to have the device polling a web server periodically looking for a signal to initiate a connection, but I'm not sure how much traffic (and data usage costs) this would generate as the device would have to poll every 10 seconds or so in order to make sure it initiates it's connection within a reasonable time frame of the request being set on the web server that it polls.
Is there any commonly used method of achieving something like this? Any general ideas or insight would be much appreciated
Thanks,
James
I think the solution will depend largely on your particular applications and requirements.
There are several ways to achieve this type of functionality and it looks like you have covered some of them already. The most common are:
have the device poll the server. This may be ok depending on the response times you need. If you need to poll as regularly as you suggest above then I imagine power may be more important to you than data rates, especially if you are battery connected. With a typical 3G data plan the polling itself will have a negligible data overhead, I would think.
have the server send a SMS which then triggers the device to contact the server. You need to make sure the SMS variable delivery time is ok for you and you also have to be aware that SMS delivery is not guaranteed so you would have to build in some sort of check for delivery at a higher layer (or into your application).
use some low cost Android based device for your 3G connectivity and leverage the Google push notifications mechanism
It is worth noting that server polling typically gets very bad press as it is seems intuitively wasteful to have the client and the server constantly checking for messages, especially when the actual messages are fairly infrequent. However, underneath most push solutions there is still a pull mechanism in the background, albeit generally a very efficient one that may, for example, piggy back on other messages between the network and the mobile device and hence have minimal power and data overhead. Personally, I would say that if you do not have major concerns with battery/power or with the load polling might generate for your servers, then it is worth exploring if the simplicity benefits of a polling solution outweigh its other disadvantages.
I have an idea of an application that involves a "chat feature", basically an ability for people to chat with each other. Since sending messages through a server would be slow (plus it would be pretty bad having to check the server every second if you have new messages) I want to use sockets to have peer to peer chat ability instead of going through a server.
My 2 questions:
1) Is socket programming the most optimal way to develop a chat program? I know there is push notification service, but I don't think it can be used for a chat program too well. Going through a server seems kind of bad if you imagine 5,000 people chatting and having to poll the server every second.
2) Will Apple have issues approving an app that has peer to peer chat program that uses sockets?
Thank you.
Sockets are indeed appropriate. But you are better off with a client/server approach rather than a P2P approach.
Having worked on a very well known instant messaging service for many years, I can tell you absolutely that going through a server is not slow - as long as your server is not slow.
Client/server has lots of advantages. Namely, it's not as difficult as any sort of P2P connectivity where such issues as NATs and Firewalls make direct socket connections difficult and unreliable. Besides, you would need a messaging service anyway for clients to exchange IP addresses.
Your stated assumption that a client or server would have to "poll" is not how scalable systems work. You should use a persistent TCP socket and look at scaling a socket service up though any of the available async methods that exist today. select(), poll(), epoll on Linux, and IO Completion Ports on Windows are all techniques for having thousands of sockets simultaneously connected without periodic polling.
My suggestion - just deploy an XMPP/Jabber server. Most implementations scale up nicely to the thousands of clients. Then your chat program is just an XMPP client socket. Some of the Jabber servers even support HTTP connectivity for situations where a user's only access is via an http or http proxy server. I played around with Openfire a while back and was reasonably impresseed.
I'm fairly certain that iOS has sockets, and that it's allowed by Apple. I only know via second hand from folks that have worked on iOS products. You probably shouldn't use the push notification service for anything more than notifications to wake up your app that there is something it needs to do.
Hope this helps.
I was wondering is there an easy way to communicate between iphones over the Internet(Not LAN/Bluetooth) or must there be a dedicated server in which all the iphones running an application needs to connect to?
For instance, suppose I'm writing a game which works on the Internet. Once four clients joins a room, game starts. must I implement a server in which every Iphone client connects to (for instance if server was developed on Windows it could be a Service) or is there another way to address this when developing Internet-based application?
Thank you
We have an online game that uses the iPhone (see www.ownthisworld.com if you want an idea of what we have done). Basically we use a php back end that accepts requests and returns xml data to the phone. It works quite well, but it depends on how much data you would be sending and your expected response times. In any event, our architecture of PHP/MySql backend works fine for our needs. By using the normal internet route, you do not have to worry about firewalls so much either.
You'd at the very least need some sort of central match making service so that the iPhones would be able to find each other, which would require some sort of dedicated server.
Secondly, devices on the internet can't always simply do a direct connection with each other. If all of the devices are behind a NAT or a firewall that doesn't allow incoming connections, you'd need a central dedicated server to host the game on. If at least one of the iPhones can accept incoming direct connections, you could have that iPhone host the game for the others.
There are some ways to punch through a NAT, but they're generally pretty horrifying in their complexity, and you'd still need the central match making service to pair up players.