I am developing an picture sharing application with messages. Now want to know how to make it instant just like Viber or whatsapp. The timer of more than a minute is not a good idea the user will have to wait for a long time for the message to arrive. And HTTP request every second will have a lots of overload on the server.
I have heard about the socket programming but not sure if it is the best way. Also how to implement that?
So the question is What is the best way of implementing this kind of application?
I am using IOS and PHP as a server language.
There are two approaches:
You can use your own protocol over any kind of socket you want (most probably a TCP or SSL stream), and then you need a server at the other end that keeps these connections open and send notifications on the right connections when something happens (new message...). There are probably existing frameworks for this, though all I can think of right now are more geared towards integration with web applications rather than native ones. Note that this will only work as long as you app is active in the foreground. This also means you will get as many simultaneous connections to your server as there are apps running, so you may have a scalability issue.
or you can use Apple Push Notifications to send notifications to the app that there is something new happening. You may include all the relevant data in the payload, or you may trigger a connection by your app to fetch the rest of the data. This will work both in the background and the foreground, though slightly differently.
You may also mix both: use APNs when your app is in the background, and you own connection when it is in the foreground.
Related
I am trying understand websockets.
I have seen 2 examples here in doc and also here.
Both examples are using endless loop cycling, listening for when a new client connects, when they do something interesting and when they are disconnected.
My question is: Is using websockets (with endless loop cycling) better than an ajax solution with http requests per x time ?
AJAX and WebSockets are vastly different. Asking if one is better than the other is like asking if a screwdriver is better than a hammer.
WebSockets are used for real time, interactive communication. Both sides of a WebSocket connection can send data and it will be received within milliseconds by the other end. The connection stays open, reducing latency due to connection negotiation.
However, it only sort of plays nicely with HTTP. That is, it plays nicely with proxies that are WebSocket aware, and with firewalls. WebSocket traffic is most definitely not HTTP traffic, except for the client's first packet, which requests switching from HTTP to the WebSocket protocol.
AJAX, on the other hand, is pure HTTP. The only difference between AJAX and a standard web request is that an AJAX request is initiated by client side scripts and the response is available to that same script rather than reloading the page.
In both AJAX and WebSockets, the client scripts can receive data and use it within that same script. That's where the similarities end.
WebSockets set up a permanent connection and both sides can send data at any time, or sit quietly at any time. With AJAX, the client makes a request and the server responds.
For instance, if you were to set up a new message notification system, if you were using WebSockets, then as soon as a new message is available, the server sends it straight to the browser. If there are no new messages, the server stays quiet. If you were using AJAX, the client would periodically send a request to the server, which would always respond, either saying there were no new messages, or delivering the notifications that are pending. There is no way for the server to initiate things on its end, it must wait for the AJAX request.
Server side, things diverge from the traditional PHP web development paradigms. A typical WebSocket server will be a stand alone, CLI application running as a daemon. (If that last sentence doesn't make sense, please spend a while taking the time to really understanding how to administer a server.)
This means that multiple clients will be connecting to the same script, and superglobal variables like $_GET and $_SESSION will be absolutely meaningless. It seems easy to conceptualize in a small use case, but remember that you will most likely want to get information from other parts of your site, which often means using libraries and frameworks that have absolutely no concept of accessing data outside of the HTTP request/response model.
Thus, for simplicity, you'll usually want to stick with AJAX requests and periodic polling, unless you have the means to rethink the network data and possibly re-implement things that your libraries automate, if you're looking to update standard web traffic.
As for the server's loop:
It is not a busy loop, it is an IO blocked loop.
If the server tries to read network data and none is available, the operating system will block (pause) the script and go off to do whatever else needs to be done. In my WS server, I block waiting for network traffic for at most 1 second at a time, before the script returns to check and see if anything else new happened that I should notify my clients of. Typically, this is barely a few milliseconds before the server goes right back to its IO blocked state waiting for new data on the wire. Some others have implemented my server using LibEv, which allows them to respond to events outside of the network IO without having to wait for the block to timeout.
This is the way nearly every server does things. This is why you can have Apache actively listening and serving web traffic without every server that runs Apache being pegged at 100% CPU usage even when there is no traffic.
In closing, WebSockets is a wonderful technology, but web libraries and frameworks are simply not built to use them. Thus, unless you're working in a system where waiting 3 seconds for a full AJAX request is far, far too long, it's probably best to use AJAX. If you're writing a multiplayer interactive game or a chat system, then you've found a perfect use for WebSockets.
I do heartily encourage everyone to learn WebSockets... but it's not a magic bullet, and few parts of the web are designed in ways where people can get real use out of it.
Yes, sockets are better in many cases.
It's not forever loop with 100% cpu utilizing, it's just liveloop, which exists in each daemon application.
Sync accept operation is where 99.99% of time we are.
Ajax heartbeat is more traffic, more server CPU and memory.
I too am in the learning phase. I have built a php-based websocket server and have it communicating with web pages. Perhaps my 2c perspective is useful.
Getting the websocket server (wss) working using available sources as a starting point is not that difficult, but what to do with it all next is.
The wss runs in CLI version of php. Late model browser loads a normal http or https page containing a request to the wss, along with anything else that page needs to do, a handshake occurs. Communication is then possible directly between browser and wss at the whim of either end. This is low overhead and hence fast and simple. Very cool. What is said over that link needs to be understood by both ends - subprotocol agreement. You may have to roll your own in php and in javascript. No more http headers, urls, etc etc.
The wss is a long-lived, stateful instance of php (very unlike apache etc which forget you on sending the page). An entire app can be run in the wss instance, keeping state for itself and each connected client. It used to be said that php was too leaky for long life but I don't hear that much any more. But I believe you still have to be careful with memory.
However, being a single php instance there is not the usual separation between client instances. For example statics in classes are shared with every class instance and hence every client. So for a single user style app sharing data with a heap of clients this is great. I can see that Ajax type calls can be replaced in this way, but if the app still had to rebuild state to service each client, and then release it to save resources, that seems to lessen the advantage.
Going a step further and keeping truly stateful instances for clients seems like a possible next step. Replicating the traditional session based system is one possibility, alternatively fork new php interpreters and look after communications between parent and children via sockets or suchlike. But this would require resources per client that would be severely limiting for any non-trivial app.
Or perhaps it is possible to put the bulk of the app in the parent and let the children just do the very client specific stuff. Or break the app design into small independent units that can communicate directly via sockets. Socket communication does seem to be catching on nowadays.
As Ghedpunk says in so many ways, the real world does not yet seem ready to realise the full potential of the web socket concept but it can certainly replace Ajax. The added advantage of the server sending without being asked opens up new possibilities previously too difficult to consider.
I'm creating a mobile app with a server backend that will authenticate a user and continuously send them updates whilst listening for post data from the mobile app. These updates will be specific to the person, pulled from a database.
From my research it seems that I should use a websocket. I'm familiar with PHP so have tried Ratchet. I've created a simple chat script with Ratchet which queries a database onMessage and sends the data to the client.
My question is, are websockets right for this? When a server receives a connection it must query the db every 5 seconds and send updated info to the app. It must listen for messages that will change the db query. Everything in Ratchet's docs seems to be focussed on subscriptions to topics rather than treating each client individually, although I've gotten around this by using:
$client = $this->clients[$from->resourceId];
$client->send("whatever_message"):
Am I complicating things by using Ratchet? Or should I use a child process to handle each client?
I am sorry for a vague questions. I've researched as best I can but cannot establish whether I'm heading in the wrong direction! Thank you for any help.
That is a good formula. Sending post data from the apps while maintaining a socket connection is a good distribution of processes. However PHP might not be your best option for running the socket server.
The reason for this is PHP is a single threaded language which doesn't sport an elegant event system.
Take NodeJs as an alternative. It too is single threaded, however you can register events on socket servers allowing the software to run additional control processes while it waits for network activity.
This does not limit you to javascript however. Work can still be delegated to PHP processes from the NodeJs application (I use NodeJs as an example only, there are other options such as Java, Python, or good ol' native).
For moving work to PHP, you can either execute commands, or use a job server to enable synchronous and asynchronous tasks.
Here are a few resources you can combine to accomplish this:
http://nodejs.org/
http://socket.io/
http://gearman.org/
http://php.net/manual/en/book.gearman.php
And if you are using Symfony:
https://github.com/mmoreram/GearmanBundle
I am building a website in PHP that handles the sessions in Redis in JSON format.
This way the session can be accessed by both the PHP interpreter and a node.js server.
What I am trying to do is now to add notifications in said website; the procedure I was thinking of is the following: (just figure it as a simple friend request to simplify it all)
user A sends friend request.
PHP uses cURL to say to node.js service to send notification
user B gets a notification because he is connected to node.js via socket.io
What are the general guidelines to achieve this? Because it looks clear to me that if user A and B are in different servers, it will be impossible to scale horizontally;
Thanks in advance.
Sounds like a you could make use of Web Sockets here with a Publication / Subscription protocol, architecture.
You get Server client functionality with web sockets.
Node is a perfect choice for a websocket server, lots of small IO.
See http://en.wikipedia.org/wiki/Web_sockets
I'm wouldn't think if the shared session is required for php - node communication, just have your clients push requests through the socket and handle the reposes as needed.
I think the approach you propose sounds quite reasonable. However, instead of doing a direct request to the service, you could consider using a message queue (zeromq, rabbitmq, whatever) which would allow you to scale it more easily as you can easily add logic to the queue processing to pass the message to the correct node instance.
I managed to get 1400 concurrent connections with socket.io on a cheap VPS with no special configuration so even with no tricks it should scale quite well. In my case most of these connections were also sending and receiving data almost constantly. It could probably have handled more than that, 1400'ish was simply the max number of users I happened to get.
Though I'd worry more about getting all those users first ;)
Use Redis's built in pub-sub capability. When the PHP server gets a request, it publishes it to a channel set up for that purpose. Each of your node servers subscribes to that channel and checks if the user involved is connected to it. If so, it sends the notification via socket.io. As a bonus, you avoid an extra network connection and your overall logic is simplified.
simply setup ur database as per required then whenever a activity is made just tell ur node js to transfer the related information through redis to php and make a process and in make a response back from php to node via channel keep checking the notification from table and show
The challenge I'm facing is simulating a communication channel between two users of a website (e.g. gaming site), by using solely the technologies mentioned in the title.
Recently I've developed an online chess website where, the idea behind which was to give users the chance to play "live" matches too, not just lengthy games where you would make a move, then come back in 1-15 days to see if your opponent has responded. And the way this game engine works implies sending asynchronous requests to the server, both to update the info related to the game (in case you make a move), but also to verify if anything has changed (if you are waiting for the opponent to move).
To better explain this... the player whose turn it is (the browser of course) sends an async. request to update the game info, exactly when he makes his move. Meanwhile, the opponent sends PERIODIC requests, "asking" if anything has changed. If anything does change, the roles switch after the board updates.
Timers are behind the functionality of the engine, so my question to you is this: How would you go about simulating a com channel between two players, while trying not to put too much stress on the server, but also having games update as fast as possible, in order to maintain the "live" feeling to it. This is most important in 1 minute games (one of the available categories). Because in that case, requests NEED to take place VERY often (at least 1 second). But server responses could delay, there would be much stress on the server when having hundreds of games available at the same time etc... so you see my problem.
I look forward to hearing from you guys and picking your brain if you have any good ideas :)
Cheers!
Andrei
PS: In case you want to try it, the name is e-chess960.com
you would want to builds a socket server. node.js would be a good javascript based library to use for a socket server. each client would create a socket connection to the socket server, then when a client sends a message to the socket server, the socket server could immediately send the message back out to its subscribers without having to store it anywhere.
socket servers require socket access, which usually requires a vps instead of a shared server.
to make the solution work, you would require that the clients have the ability to create socket connections to your server. some browsers already can as part of html5, but not all yet. you could also use Flash as a way to create a socket connection.
What you actually want is not pulling the server every second, but instead keep a connection open and use the observer-pattern to distribute updates to the specific clients (in other words: push instead of pull). That way, your server resources will not get swamped by a new connection for every second and every client. A library to accomplish that is the Comet Library. Check out this nice tutorial for a sample application.
How to make php client to client, like the chat way ? One client connects and sends something to the other client and only he recieve not all clients.
Your Question?
If I understand correctly you want one-to-one(private) messaging.
Socket Programming using PHP
You need to learn Socket programming with PHP. You could start by studying this tutorial. This has scaling problems written all over it, because PHP does not have non blocking IO, proper thread model. I advise you to just use it for fun little projects.
Non blocking IO using PHP
You could try and use PHP-MIO. I have not yet tried this, but I guess it might scale. But then again from Apache(PHP) side you will have the same problems. But when using this from both sides it could work...
long-polling(blocking IO) using PHP
P.S: got bored so I have not completely tested this ;)
Download
Below I present two solutions(prototypes) which do NOT scale. One solution uses Redis pubsub. For this you need to install(compile) redis. For this you a POSIX OS is desired, although some people have ported it to Windows. You can also use the free redistogo.com instance. The Redis solution is the prefered solution. I have put everything in an archive which you can download from here.
I also give a solution which uses named pipes. This solution does not require you to use Redis, but instead this approach needs access to the file system. I believe that this approach should also work on Windows(You have to change the filename to windows-style). I would like for somebody to try this out :). I can not test this anymore, because I have completely switched to POSIX OS(Ubuntu) a long time ago.
Requirements
At least PHP 5.3 and preferable a POSIX OS, redis.
How to use
To use both solutions you need to open two browsers(Browser A/B). I assume you are using localhost for development and that you can access files from http://localhost/6646733.
point browser A to http://localhost/6646733/redis?me=somebodyelse&to=alfred you should replace redis with pipe when trying out named pipes.
Point browser B to http://localhost/6646733/redis?me=alfred&to=somebodyelse
In browser A type a message into the textarea, which will be sent to browser B.
In browser B read the message just sent from browser A
Solutions not using PHP
The solutions below scale.
Pusher(Hosted)
With for example the hosted solution Pusher you can do chat/messaging without the scaling nightmare. Pusher even is generous to provide a free plan. But be aware that the cheap plans do NOT offer SSL so the messages can be intercepted. You should never sent private information over the wire, when not using SSL. Users/developers have provided a nice little library to use Pusher from PHP. The problem with this approach is that you are not in control, but pusher is, but then again you don't have to worry about any details.
Socket.io(open-source)
I really like socket.io, but there are off course a lot of other solutions like for example tornado. You could use Redis to efficiently communicate between PHP and the other solution(socket.io).
I don't fully understand what you are trying to do, but you can use some kind of database and have it store messages that is sent to each user, and then have your client page refresh the chat part with a AJAX kind of query to update the chat. It will then behave simular to the new Facebook chat, where all messages are stored even the ones sent in normal chat and mail. So clients can mail and chat each other at all times, when they are online it will show in their chat and when thy are offline it will show up in their inbox. But this might not be what you are trying to do.
For implementing best Chat application, use jabber server and write clients using js/flex
http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol
If it's not like chat but you want to send messages over without a server, you need both clients be server as well. A server will listen on a port for incomming connections. Write a daemon that spawns a new thread each time a client connects. Within this thread you handle the messaging.
Client A opens a connection to the server (Client B) and they can talk to each other. Or you let Client A become server and let Client B connect.