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.
Related
If you are trying to develop an interactive livestream application, you rely on ultra low (real-time) latency. For example for a video conference or a remote laboratory.
The two protocols, which should be suitable for this circumstances are:
RTSP, while transmitting the data over RTP
RTMP
*WebRTC: As I'm trying to give a bigger audience the possibility to interact with each other, WebRTC is not suitable. Because as far as I know it is not designed for a bigger audience.
My questions:
Which one should I choose for this use-case? RTSP/RTP or RTMP?
Which protocol delivers better results regarding end-to-end latency, session start-up time?
Which one consumes more hardware resources?
RTMP seems to use a persistent TCP connection. But which protocol is used for the transmission? It cannot be TCP, because this could not ensure real-time latency?
What are in general the pros and cons for using either of the protocols?
I did not find any comparison of these two protocols in scientific papers or books. Only that the famous mobile live-streaming app Periscope is using RTMP.
Other apps like Instagram or Facebook are for example providing text-based interaction with the streamer. If developers want to build the next "killer application" based on interactive live-streams: I think this question is essential to answer.
You make a lot of assumptions in your answer.
WebRTC: As I'm trying to give a bigger audience the possibility to interact with each other, WebRTC is not suitable. Because as far as I know it is not designed for a bigger audience.
That's simply not true. WebRTC doesn't know or care how you structure your applications server-side. There are plenty of off-the-shelf services for handling large group calls and low latency video distribution via WebRTC.
You should also know that for the media streams, WebRTC is RTP under the hood.
It cannot be TCP, because this could not ensure real-time latency?
Of course it can. There's some overhead with TCP, but nothing that prevents you from using it in a real time scenario. The overhead with TCP is minimal.
UDP is traditionally used for these sorts of scenarios, as reliability isn't required, but that doesn't mean TCP can't be used almost as performantly.
RTMP
RTMP is a dead protocol for Flash. No browsers support it. Other clients only support it for legacy reasons. You shouldn't use it for anything new going forward.
Only that the famous mobile live-streaming app Periscope is using RTMP.
Well, that's not a reason to do much of anything.
Which protocol delivers better results regarding end-to-end latency, session start-up time?
WebRTC
Which one consumes more hardware resources?
That's not the right question to ask. Your overhead in almost any other parts of the application is going to be far more than the transport overhead of the protocol used for distribution.
The real list of things you need to think about:
Client compatibility. What sort of clients must you support?
Do you really need low latency everywhere? Do you understand the tradeoffs you're making with that demand? Are you willing to destroy any sense of video quality and reliability for all your users if only a handful of them are going to be interactive?
What's your budget? Off-the-shelf solutions for distribution are much cheaper. If you can push off your stream to YouTube for non-interactive users, you can save yourself a ton of money. If you can't use existing infrastructure, be prepared to spend mountains of cash.
What are your actual latency requirements? Are you prepared to reduce the number of people that can use your application when these latency requirements cannot be met on crappier networks and mobile devices?
What are your quality requirements?
Where will you transcode video to a variety of bitrates?
Do your viewers need adaptive bitrate viewing?
Do you need to push streams to other platforms simultaneously?
Do you need to record the streaming for on-demand watching or going back in time?
You might also find my post here helpful: https://stackoverflow.com/a/37475943/362536
In short, check your assumptions. Understand the tradeoffs. Make decisions based on real information, not sweeping generalizations.
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.
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.
I'm kind of curious how I should approach a problem with iPhones and communication between two phones.
I have an idea for an application that needs to send data between two known phones. The problem is that the data could be very small or very large. I want to have intermediate storage on a server and a messaging layer, but I want there to be performant means to communicate between devices for shorter, unimportant messages.
You always hear about networking and client to client communication with popular platforms and protocols, but I'm curious what people's thoughts are on doing p2p style communication with an iPhone.
I'm pretty sure it should (and can) be treated as just a simple addressable machine... so I would have to build NAT traversing network code into the iPhone itself. A thought I had would be some sort of UPnP situation where I would ask to NAT a particular port for communication to the devices... but I guess I could just as easily turn it into a polling situation.
Granted, I understand that Apple will have a "push" mechanism for developers eventually but I want to get the app out the door before hand...
Just curious about thoughts on this type of thing... any thoughts on multi-player game situations would also directly apply to (and benefit from) this question.
Have you given the WiTap sample from Apple a try? It addresses the issue of discoverability (via Bonjour) and connectivity (via basic TCP). It may not be as robust as what you are looking for, but it's worth a look:
http://developer.apple.com/iphone/library/samplecode/WiTap/index.html
Look at the docs for Game Kit in the iPhone 3.0 SDK. It allows iPhones to connect to one another locally with Bluetooth, or via wi-fi/3G. It addresses both peer-to-peer and client-server architectures. It provides unreliable and reliable links.