I'm developing an app that will have a way to message other users. I've done this before but I think I can improve on the method of sending/receiving the data. Before what I did is I had a table with all the messages and the ones that were associated with the conversation ID would be displayed in an individual conversation. On the client side, I'd have a timer that would constantly ask the server for an update.
I guess my question is this: Is there a better way than to keep asking my server if there is an update? I mean.. a lighter way. I was considering using push notifications but if the user disables APNS, their messages won't update.
http://reactphp.org/
Is useful for event driven socket based communication. It would involve storing connected clients in some kind of data structure (see here) and on an event, such as a change to data, notifying connected clients that should know about the event, in the manner of a push.
http://socketo.me/ is built on top of react
http://socketo.me/docs/flow
has a good diagram of how socket based connections work. This might be better than polling repeatedly from all the connected clients, based on your use case.
Related
I am currently creating an app where 2 users will have the ability to chat with one another. Specifically, it will be an iOS app using Swift as the main language. Most chat app tutorials on the web recommend using Firebase but I personally want to use MySQL since the rest of my database activities for this app are done using MySQL. I also do not want to use any existing libraries and want to do this all on my own.
I only have questions regarding the efficiency of using MySQL. When accessing the database, I create a URLSession using swift which then uses a predetermined link that points to my PHP scripts on the backend to handle the database accessions. The only problem with this is that my chat functionality of the app will have to refresh messages (to see messages that the other user has sent you within a second or so). I am confused as how to go about this. My current idea is to have a Timer that calls the URLSession data task every second or so to retrieve new messages from the database then display them on the user's screen. Would this be efficient or is there a better way to do this? I feel as if this would bog down MySQL in some way and would over all slow down the efficiency of the database. Is there a better way to go about this?
Thanks in advance.
If you really want to use MYSQL as a way of delivering messages then you can look into #TekShock's comment about using Apple's PushNotifications. You can also use Long Polling however it is not favorable at all.
I personally would not use MYSQL as a way of delivering messages just because there is a lot more better options. You can pick from messaging protocols like XMPP and MQTT to deliver your messages. I have personally have used MQTT in the past and thought it was really simple to get the hang and will fit your needs perfectly. It has a couple of really good swift clients like SwiftMQTT. You will have each device subscribe and publish to a room so it can receive and send messages. So in your case you can have a User A subscribe to ROOM 1 and a User B subscribe to the same room and they will both receive all the messages published to that specific room.
You can then if you want to store delivered messages to a MYSQL db so when the user opens the app back up you can load all their previous messages. You can also use Sqlite or Realm to store these messages locally instead of storing them online.
EDIT:
Scaling is also pretty simple with MQTT if this is something you will consider. You could place a queuing system between your application and the MQTT broker, possibly something like Apache Kafka which would be your best bet.
I want to keep a persist connection between my server and clients (android app) so I can push data from server to my clients. After some search I found that the best way to do is WEB SOCKET. But there is two scenarios in here:
first is, I need to sent some data (command) like broad cast to some of my clients (not all) and then listen for their reply. And second is, I need to sent a notify to some of clients.
It's like chat room that there is a general room that the messages can be seen by everybody in room and some private rooms that messages can be seen just by two users who participate in chat.
I saw some example code but I couldn't understand the different between those two scenarios in codes. I need also some information about ZeroMQ and does it worth to use ZeroMQ for the project or not?
Just some links of references would be appreciated.
EDIT
I saw in code that people define some infinite loop to check some event but my idea is to create a virtual client in server that can call by other function so I don't need to change anything in DB and then check for event in my loop. the event can call this virtual client that can sent my command in broad cast. is that a proper way to do that?
Use Ratchet for this, It is a PHP library providing developers with tools to create real time, bi-directional applications between clients and servers over WebSockets.
You can use it's subscribe/unsubscribe (Topics) feature, which will fulfill your needs to send push notification in general and to specific users. Create different topics for them.
e.g. One topic would be general for which every user will get registered on page load and one would be for specific users. You can create as many as topics you need.
I am working on a project where i am trying to build an interface like If user is logged in and in between that if sever has any message for that user then the user will get notify immediately (Like facebook ) so for i am going through websockets but confused from where should i start ? please suggest me some basic ideas ?
I am using PHP as a language for implementation
I'm looking for advice at the moment on achieving real-time notifications using a mix of PHP, NodeJS and socket.io.
At the moment I have done next to nothing with Node and socket.io so I'm at a loss with the best way to achieve this. I've done some basically listening and what not but nothing extreme.
For now my questions are:
How will socket.io know of new notifications, should PHP be responsible for sending the data (say a post was created) to socket.io and from there broadcasting to connected clients?
How does socket.io know which clients want the notifications?
I'm really not sure what else. This is all a bit much for me at the moment. I just can't get my head around how the notifications will be distributed.
Any advice would be greatly appreciated. I don't expect a detailed walk through, just a push in the right direction or some knowledge on how it all meshes.
Start from reading what is websockets, how they work, what browser support. The internet is full for this information.
For php implementation, take a look at the http://socketo.me/. PHP is not best suited for socket communication. I would use nodejs+socket.io and php for 'regular stuff'. Don't be afraid to mix technologies, there is no hammer for all problems.
Edit:
If you don't know nodejs then it could be hard, but it's worth your time to learn it.
Some ideas:
You can create table with notifications on your database, then if some event acccurs, ex. post added add record there (like number of new posts, and user_id), then from nodejs side connect to database fetch database and look for notifications for current user.
Then nodejs notifies listening clients about changes (socket.io)
If user reviews new posts update counter to 0, (something similar what facebook does when you have new message), and then nodejs will know that there are no new post, so nothing to notify.
The hardest part is to get current user session.
Some related:
http://socket.io/
What MySQL drivers are available for node.js?
Sharing data between php and node.js via cookie securely
Authenticate user for socket.io/nodejs
Socket IO send to specified user ID
I'd like to create an application where when a Super user clicks a link the users should get a notification or rather a content like a pdf for them to access on the screen.
Use Case: When a teacher wants to share a PDF with his students he should be able to notify his students about the pdf available for download and a link has to be provided to do the same.
There are several ways you can accomplish this. The most supported way is through a technique called Comet or long-polling. Basically, the client sends a request to the server and the server doesn't send a response until some event happens. This gives the illusion that the server is pushing to the client.
There are other methods and technologies that actually allow pushing to the client instead of just simulating it (i.e. Web Sockets), but many browsers don't support them.
As you want to implement this in CakePHP (so I assume it's a web-based application), the user will have to have an 'active' page open in order to receive the push messages.
It's worth looking at the first two answers to this, but also just think about how other sites might achieve this. Sites like Facebook, BBC, Stackoverflow all use techniques to keep pages up to date.
I suspect Facebook just uses some AJAX that runs in a loop/timer to periodically pull updates in a way that would make it look like push. If the update request is often enough (short time period), it'll almost look realtime. If it's a long time period it'll look like a pull. Finding the right balance between up-to-dateness and browser/processor/network thrashing is the key.
The actual request shouldn't thrash the system, but the reply in some applications may be much bigger. In your case, the data in each direction is tiny, so you could make the request loop quite short.
Experiment!
Standard HTTP protocol doesn't allow push from server to client. You can emulate this by using for example AJAX requests with small interval.
Have a look at php-amqplib and RabbitMQ. Together they can help you implement AMQP (Advanced Message Queuing Protocol). Essentially your web page can be made to update by pushing a message to it.
[EDIT] I recently came across Pusher which I have implemented for a project. It is a HTML5 WebSocket powered realtime messaging service. It works really well and has a free bottom tier plan. It's also extremely simple to implement.
Check out node.js in combination with socket.io and express. Great starting point here
I'm using PHP, AJAX, a MySQL database, and a lot of jQuery to prototype web-based chat system (similar to Facebook Chat). I'm stuck on how to "listen" for incoming chats... when to know someone is trying to chat me... and to know that it is a new chat, not an existing chat.
Right now, I'm polling to see if there has been new insertions in the database tables but it seems very inefficient... a lot of overhead for the server.
Is there a way to receive a notification when, for example, a row has been inserted in a table in a MySQL database so that instead of having constantly poll, I can just be notified and then go look at what as inserted?
If there is a better and more efficient way to create this one-on-one chat relationship, please give me some suggestions.
Thanks, Hristo
You have to use polling, but you can use a technique called Comet which involves long-polling, i.e. sending out an ajax request that will be held by the server until a chat request comes in.
http://en.wikipedia.org/wiki/Comet_(programming))
I think polling is the only way for JavaScript to be pushed server side changes.