I'm creating a viber-like application, i.e. android users can make instant messages in their android-powered devices. I've created client-to-server webservices using ASP.NET (ASMX service with JSON response) and it works like a charm, but the other side, i.e. server-to-client requests is just a little headache. Of course I can make my application so that there is no need to server-to-cliend requests (sending dummy requests from client to server in short periods) but in this way server will be overloaded specially when number of users increases. I've found some technologies regarding instant messaging, including GCM and XMPP. What are my other options? or let me ask what is my best option?
Should I use sockets? If so, how can I always have my clients IP (considering that clients are mobile users which may be using WiFi or GPRS/3G/4G internet). I'm thinking of a system in which my clients send their IP each n seconds (n can be around 30), so server always has a (nearly) up-to-date list of client IPs.
Is it possible or even logical to do so?
You should definitely consider using GCM (Google Cloud Messaging for Android)
You need to setup a few things in your server to be able to use it to send via GCM.
Its the built-in way to send data from a server to an android device, hope this can help
Implementing GCM Server
Using the good old strategy of long-polling is always possible, but there are much better ways to do it nowadays. That's perhaps the fastest to implement of the mentioned (not so if you want to implement it correctly and with min amount of load on your server/DB engine). I've seen some projects that start around that architecture with the idea to move to something better in the future .... and the moment to move never comes of course. If you start browsing your Android phone connected to a proxy like Charles you'll see what I mean :)
WebSockets are an option, but I don't see a reason why I'd use them for a Viber-like app, which is event-based (you've received a message) and not "real-time" (monitoring some stock graphics movements for example).
Your best choice here is a Google Cloud Messaging (GCM)! It's easy to implement it both on your backend and on the client, and it's built specifically with the problematic connectivity in mind (switching between wifi/poor 3g/4g/etc). It has some pretty nice features that other methods don't provide "out of the box" - message resending (the common scenario of a client loosing his connection - GCM it'll send the push notification later, when he comes online), automatic syncing between devices (smartphone, tablet, etc) and others.
Related
Is it possible / does it make sense to use an Android app as a "Producing client" for Apache Kafka?
Let's say my Android App need to capture and analyse reaction time data. Goal is to collect all data and show the average reaction time in real-time in the App.
The alternative is having an app server of some kind as an
intermediary that accepts messages from the android app and posts them to
Kafka, rather than having the app be a Kafka Producer on its own.
Even if it's possible, in my opinion it has some disadvantages.
In general I like clients to be as simple as possible to avoid maintenance issues. Instead I'd route all client requests through a REST API on my app server. The disadvantages are not related to Kafka, but are common problems of native clients.
Coupling
You're coupling the Android app closely to your messaging infrastructure. If you later decide that a Kafka solution is too much and Plain Old Java would be good enough, you'll first have to update the Android app and wait until enough users do an update.
Network issues + delivery guarantees
Kafka clients also require a direct connection to each of the brokers. Mobile clients can have very inconsistent/spotty network connectivity, making direct client access susceptible to dropped events and overall network connectivity issues.
Authentication
Probably you already have some kind of authentication in your app. You can also create authenticated connections to Kafka. So you'll have two authentication paths, whereas with an app server Kafka only needs to check if the requests are coming from the trusted app server, which means less implementation effort.
...
I think it would make lots of sense:
Kafka-clients.jar provide auto-reconnecting capability which is very useful when the phone is on a flaky internet connection
The Kafka-clients.jar is quite thin and does not include any of Kafka Server code (it doesn't even depend on Scala).
Unfortunately, it isn't compatible with Android just now: KAFKA-7025 . If you'd like to see this happen, please upvote the JIRA issue.
I believe that an Android Application can use a secured connection to a Kafka Broker cluster using SASL, for example. However, it must be done in coupling with any other communication, which can support synchronized keys rotation, which is initialized by any remote server with synchronization with the broker's cluster.
Any concrete instance of mobile application can listen to a concrete topic, and produce messages to a related topic, which is created when registering the instance using a REST server. Any deserializer verifies headers or Keys for a token, which are appointed using REST while registering on the same service. Custom encryption can be provided similarly.
Technically it is solvable. But what are the benefits, in front of using Firebase, for instance? Expenses I see from the start. Benefits???
I am making a chat application for android. For that, I decided to use GCM (Google Cloud Messaging). But having researched a bit about it,I have read that it shouldnt be used for something like chat.
I will be implementing Upstream messaging (sending data from the device to the GCM directly, without a send-to-sync). Here are my concerns:
Will the messages transfer instantly? (will be fast enough that the user can see 'typing'/seen)
If all devices are online, what is the guarantee of the message from GCM reaching the client.
The main reasons I want to use GCM is
GCM uses the least amount of battery life
This is an android-only app.
If GCM is not what I should use, what should I use?
I am working on a similar requirement and Looking at the requirement of being able to show feedback such as typing/lastseen etc, as per my knowledge XMPP based solution would be appropriate.
you can try with available xmpp server like ejabberd/mangooseim (open source) by installing it on your server and use asmack or any other client side java library to communicate it with your server. (There are lot of tutorials available for this).
With this much setup you will be able to get to the stage where you are able to get status such as "typing", "gone" which whatsapp and also some chat clients like gtalk/pidgin shows.
It would roughly give an idea of how existing chat clients work.
Ejabberd is completely written in erlang and if you want to extend any functionality erlang knowledge is must. (it is specifically designed for highly concurrent fault tolerant and non-stop systems, which was helpful in chat applications.
GCM would be definitely able to communicate between the android phones 99.99%of times with not much delay but if you want to have roasters status like normal chat applications, you will have to reinvent the wheel completely.
Update:
Here are the considerations.
from client A to client B I want to send chat messages with roasters and dont require to store messages on any central server but just on the clients - XMPP (like whatsapp)
in case you require all the communication to be stored in server - XMPP with sql driver or mongodb driver / gcm (Depending on your time and resources)
in case you require communication between devices not necessarily chat, then gcm should be sufficient.
I am using this approach in my app currently which is live on playstore with beta version and it absolutely works fine in most of the cases. I havent seen much of bottle necks as of now.
I recently created an app that sends and receives commands in the form of SMS text messages, being that sending a lot of text messages could become quite costly, i'm now looking for a new method to use to send and receive the data securely over the internet. Obviously one solution would be email, although I do not think this would be ideal due to emails stacking up and accounts etc.
So basically, i'd like some advice on what my other options are....
How would sending a command using TCP work in android and how secure would it be?
How would one go about setting up sending data over TCP?
Any feedback would be great, thanks
What your looking for is Google's Cloud Messaging service. GCM is the standard way to push messages to/from the client. It requires several components to implement, however. One being a database to store GCM ids. Another is a back-end to do this.
It essentially works like this:
User downloads and installs and opens the application
Your application sends a request with your application's unique identifier to google for their GCM id (have to register on google's app center site)
Google responds to the device with their GCM id
Your application then sends (via network services or ajax in a webview) their GCM id to your server, which stores it for future use.
All of these components, however, are good things to have for growth and infrastructure support. Postgresql is a good, open-source relational database.
Other options:
1 - You could use websockets (https://github.com/koush/android-websockets)
Websockets, however, could considerably draw down the user's battery, extremely quickly if the app communicates even if it's not open, like... 'whooosh'
The benefits of using websockets is that it detaches your communication from Google.
Depending on your principals and/or beliefs, you may choose to go 100% independent by using soon-to-emerge web standards for detachment. Google (lol) "Extending the web to support personal network services" written by John Lyle, Claes Nilsson, Anders Isberg, and Shamal Faily. It's a good paper on the mobile communication debate.
I am working on a multiplayer turn based word game for iOS/Android and need to make a server. I have researched and found google app engine. I believe I will use GAE with python but I am open to other suggestions or possible problems.
My plan is to send HTTP requests to the server from the client and have the server respond with JSON. However, I am not sure how to have the server contact a client when the other player had finished their move. Do I check the server every x seconds or is there a better way to do this?
Is there any other information I should know about GAE or turn based servers/games in general?
You have two options:
You can check the server every few seconds or so to see if there are any updates. This system is good as it is much easier to do than the second option; however, this will use more battery life, burden your server unnecessarily, and could be delayed.
Your second option would be to use push notifications. iOS and Android have their own push notifications systems, and you are even able to embed information in them (such as a message, if necessary, or a Game ID). This saves battery life, and the server is not burdened by many devices checking for updates every few seconds. Instead, the server notifies each device when an update is available. This system could be more difficult to make, but it is worth it in the end. Use push notifications.
iOS/Android each have their own native notification systems (iOS Push Notifications or Google Cloud Messaging). You should use those. Or you can use an abstraction like UrbanAirship.
I have developed a simple two player chess game in android to be played using Bluetooth. I want to extend it by making it possible to be played through internet. whenever a player makes a move, the move should be transferred to the other player via internet.
How to make this possible?
I have heard of C2DM mechanism.Does that suites the scenario i described and is it reliable?
Thanks:)
Yes, C2DM is ideally suited to this type of game. This is what I am using for my own game (http://www.chesspresso.net) which is a correspondence chess client for android.
Things to consider when using C2DM:
You don't send the info to the devices, you notify the devices that a move has been made. You don't use C2DM to transfer data, you use it to notify that something has changed.
Its available for 2.2+ Android, which is the majority of devices. But if you wanted to support older devices you'd have to consider an alternative. I am using polling for older devices.
You have to request for developer access, then once your app is ready you have to request production status. If you don't do this you'll hit the developer status quota very quickly once its released! They are very generous with production quota, but you have to explain what you're using it for and it also can take a few weeks to get accepted!
Your users will have to have a google account that is authorised, otherswise C2DM won't work. Most users will have an account associated with their device, but some don't so this means that you'll possibly want to validate for the presence of an account to notify the user.
Its reliable, but every now and again a device will have to wait for the message. Sometimes a few minutes. Usually its instant.
Hope that helps!
UPDATE:
C2DM has now been deprecated, and replaced by Google's GCM.
Also, I strongly suggest looking at other options as tying yourself down to a Google specific API means you won't be able to support external marketplaces. For alternatives, I am currently evaluating Amazon SNS and I will also be looking at Urban Airship. There are possibly other alternatives I have not considered evaluating yet.
UPDATE:
Evaluation update of non google based push notifications:
Amazon SNS is just not a project for this task and Urban Airship for the vast majority of apps is too expensive. Unfortunately all the other alternatives are all very expensive also, especially if your app (like mine) relies heavily on push.
A good way of doing that is using a simple direct TCP connection between the peers.
If you're new to socket programming on Java, try this:
All About Sockets
Another option is to use some sort of IM as a communication medium for app. For eg. Use Asmack to connect to XMPP Im like GTalk. Prompt user to create an account there, for your game.
And use it to send and receive commands via IM. This way you won't need to setup your mediating server.
This works if user knows who he is playing with. To collect the user data and let them search for available players, you still need to setup a server. IRC chat room may be an option to avoid this also.
GTalk was just an example. You can use any IM or IRC also.
C2DM it's not design to transfer informations, even if they are small like "horse in b4" or things like this. It's designed to inform the device of something, maybe a newer version of a document or more articles on a website.. Stuff like this.. It's not designed to communicate device to device. And also it may be not fast enough for a real time chess play.
You should look for a more traditional way of communicate via internet or to search for some libraries (I'm pretty sure that something exists..) that will help you.
IMHO, C2DM is exactly the kind of thing you would want for a chess game; to be notified when the oppo has made his turn (which may be minutes /hours / days later ?). I have discussed my game with a few google android devs and they've stated that C2DM is ideal for this. You'll need to go via a centralised server though (well, not essential but very advisable) as there may be issues with resync'ing game state etc. Worried about "hitting the limit" ? Well, for a start my c2dm acct is restricted to "just" 100,000 messages per day. I guess you're buying the drinks if you hit that !!
Chess is often played by email. You could do that.
Of course, any centralized/federated messaging system will work.
What might be better for your use is to add a jabber client to the application and have the program generate an account name that is used for automated messaging. You could host the jabber server or generate the accounts on a free provider.
Google App Engine if you know Python or Java.
Alternatively there are two web app API styles in wide use today: SOAP XML and RESTful web services.
If you know RoR I would recommend using JSON/REST, because you can just use Phusion Passenger with Apache to deploy your app. Free, extremely easy, and makes your server very reliable.
You could, and I only mention this because my friends do this all the time, use twitter as a server between the games.
I also found a lib called mages which looks quite promising.
Good luck.
I did this for my online 2D rpg: http://developingthedream.blogspot.com
Basically, use a middle-man server to co-ordinate data between all your clients.
You simply open a socket and communicate with the middle server and it takes care of passing on the information to any other connected clients.
I wouldn't recommend C2DM because of the message limit, and because the latency is still to big. Using your own server you can optimize it, plus you'll be the only one using the service so your data will be delivered faster.
I think that C2DM is not right way for playing chess because there is no warranty that messages will be delivered. You need more reliable way for data transfer