I'm trying to make a mobile application and I found ionic framework which seems cool.
It seems that REST is a common way to do things and I don't understand one thing with this protocol. How does the server notify that he has data to send. If we have a text application, how does the server notify the application (without push notification, or maybe they're mandatory ?) that another client sent you a message ?
It seems like REST is only good for the requests coming from the client. Does it means that I have to send request for update every X milliseconds to have a responsive application ? Do I have to use websockets for such purpose ? I also saw Comet, is it a good way to use rest ?
The REST architecture doesn't really address "Publication/Subscription" (pub/sub) paradigms. It's much more coarse than that.
The major issues with pub/sub are technical, especially today. In a fully connected internet where everything is online at known locations all the time, then the basic REST architecture just works. Simply, the roles of Client and Server swap back and forth (i.e. the Server becomes a Client when it needs to send an notification).
But that's not the real world.
The real world is while we have a lot of connected devices, we do not have a lot of known locations. Your phone moves around all the time, and who knows what IP address it's at at any one time. DNS doesn't help because your phone is likely not registered under any particular known name. Then there's infrastructure issues where the vast majority of clients are locked away to where they can send messages, but can not receive them, even if we did know who and where they were.
So, REST doesn't explore that area simply because it typically violates a few key attributes.
One is that the URL goes away. Since we don't know where or who you are, we can't get to you by name. So, one way folks get around it is through long lived connections. Your client hooks up to the server and retains its connection so that the server can talk back. But this is an implicitly stateful connection. REST drives towards statelessness, and is effectively connectionless at the architecture level.
So, in that environment, REST is not an appropriate architecture, since the mechanics can not support some of the fundamental precepts.
Related
As for clarification, this question is not duplicated since the
situation differs from other related questions.
We are working on an client side application which will receive data from a server side PHP-powered web application. Data are critical and must be delivered to user as soon as possible. It doesn't matter if client request for data from server or server push data to client, the only thing we need is a reliable and fast option.
There are several methods but non of them fit our project:
Use GCM push notification ability:
This is a great option but in practice, we lost several pushes so it's not reliable and in other hand, delay is so much. I repeat, the situation is critical so it must be fast.
Request data from server by the client with a 1 or 2 second interval:
This is what we think is the best solution so far but is really expensive. It's reliable and fast. But in other hand, the pressure on our disturbed servers get extremely high and they become useless even with our current client numbers. If the number of clients get larger, we'll be down.
SMS based push:
The other option for us is to send SMS to client phones and use that data to operate application. Using this method, the pressure on our server will get really low (just like GCM option). But sending SMS in our countries mobile network is usually delayed, normally, 10 seconds. Although this option have good reliability but the speed so low that we can't use it.
FM radio signal based push:
We can use clients FM radio receiver to get data from local broadcasting stations. This method is reliable and very fast but the cost of stations will kill us! and even if we handle it (read: we can't), clients does not connect their earphone to the smartphones always.
So, what are the alternatives? what is a reliable and almost fast method which does not make a lot of pressure on our servers?
Would probably recommend using WebSockets for case you describe (using OkHttp library for example) - see following for nice overview of it's use https://medium.com/#ssaurel/learn-to-use-websockets-on-android-with-okhttp-ba5f00aea988. A common pattern would be use of WebSockets with Http REST requests (for an initial catch up query for example). Also you would typically only use WebSockets while app was in foreground and rely on push notifications otherwise.
I've currently setup an Android and iOS app to use ActiveMQ MQTT for my message relays. It all works fine but I have the following questions that I would be grateful if anyone could help with:
1) As I understand, all clients need to keep an open TCP connection to the MQ server (for obvious reasons) and subscribe to topics and when a topic is published, the subscribed clients get a notification. If the number of clients is in the millions, it would mean millions of active open TCP connections. What are the ramifications of such number of open connections to a server? Is there a better way to handle the situation? Would you recommend instead to connect say once a minute or so, query for the "State of the world" (i.e. the latest unread messages) and disconnecting the clients? or am I being paranoid and millions of open TCP connections is fine?
2) On the subject of security, I understand that I can use SSL which is great but I still don't understand how to prevent a third party from subscribing to all topics (or even individual topics)? As far as I understand, clients need to connect to a server and subscribe to a topic but what would prevent a third party application from doing the same? How would I prevent such a thing and make sure that only clients from my app are able to connect and subscribe to their own topics?
Many thanks in advance for your help,
If you do reconnect , you will need to make sure your clients create durable subscriptions. If not, you miss out on anything that was published between connections. This can also be a scalability issue that you will need to consider. With millions of connections you will want to consider using a cluster, or some sort of topology that supports load balancing, regardless of approach you take. Constantly reconnecting clients can cause unexpected overhead as well as the Broker(s) attempt to keep up with everything that is coming and going. A big part of your decision will be based on your hardware as well as with any server.
This only scratches the surface of topologies, but here is a good starting point.
Edit: Added information to try to address your concerns on millions of connections that I meant to add the first go.
You can set up role based security via authentication plug-ins within ActiveMQ. Each role/group can be set up with a pattern using wild cards to allow access to a specific topic tree.
See this page for more details on setting this up.
Here is another site with good information that should answer your questions on how to and how it works.
I'm making an app using bluetooth, and I realized it'd be pretty neat to exchange data between 2 running devices via bluetooth.
However, as far as I know most Bluetooth devices use a traditional server/client architecture, so the information exchange is one sided, ie, client requests data from server, server sends it, but not the other way around.
To get around this problem, I tried to make each device have a server instance as well as a client instance, so that the client can hook up the the server in the other device. However this does not seem efficient as this requires 2 channels of communication instead of one.
Then I tried going to Bluetooth website, and they suggested "role switching", that is, when server wants some data from client, server makes itself a client and client becomes a server, so the role is reversed. I don't quite like it either, because why can't 2 devices play the same role and exchange data at the same time? What kind of connection is this called then?
I have not had experience in networking so my question might seem naive, but I'd like to have someone point out the answer, or tell me what information/which chapters of textbook I'm missing so I can wiki it.
Role switching affects the underlying Bluetooth topology: which device is master in the piconet. That can have implications for the quality of your connection, but it does not directly affect the direction of communication in the way that you are imagining: it is at a much lower level.
Yes, in Android Bluetooth comm is done using sockets abstraction and the setup of the socket connection is done in a client-server manner. But once the socket is connected both sides have a BluetoothSocket instance and I'm pretty sure that both sides can get an output stream and initiate communication. What makes you think otherwise?
As a capstone project, my group and I are designing a couple of applications for a bus line. There will be a bus side application for the bus driver to send his location to the server, the server then sends this info to a user side app letting him know whether the bus is late or on time.
I'm handling all the server side components. I'm familiar with setting up servers on desktops, but I've yet to decide on the best approach for this since I'm a little unfamiliar with mobile application servers.
The applications are being coded with Java and using XML for parsing, so we decided on an HTTP server, but I may also code an SQL database that has a schedule of the bus arrival and departure times. I just need advice on a starting point to best approach this since all of my research hasn't given a definitive answer.
http://www.liveprofile.com/
I was wondering if anyone would be able to explain roughly how an application like LiveProfile is implemented?
How do the messages get pushed over the network from one device to another. How do they know the address of the device they wish to send it to? Is there a map of IPs and LiveProfile PINs?
Is it HTTP? Just the general technology used would be a great help in improving my understanding of this aspect of Android and mobile engineering.
I don't know about that specific app, but there are several possibilities out there.
One is Google Labs' C2DM: http://code.google.com/android/c2dm/
Also, check this post. It has a very detailed explanation: http://tokudu.com/2010/how-to-implement-push-notifications-for-android/
Here is another one with useful info: http://blog.boxedice.com/2010/10/07/android-push-notifications-tutorial/
As a co-founder of LiveProfile I can shed a bit more light on what we've done.
LiveProfile was released before C2DM was available. Infact the market was fragmented and many were still using Android v2.0 and below. For this reason we ended implementing our own push based solution.
Our solution is a persisted socket to our servers at all times. When a user sends a message to another user, it gets routed through our servers and we decide who it should go to. If the persisted socket is connected then we push the data to them. If the user is not currently connected, we store the data in an queue and the user will receive all the messages on connect.
Update: A good resource is a talk from Google I/O 2009 which goes into detail about the battery life, how network / CPU effects it, etc. http://www.youtube.com/watch?v=OUemfrKe65c