How Facebook chat is working? Can anyone give me idea? I mean they are using websocket or AJAX? How they have implemented it?
It's a comet (see wikipedia) model:
Comet is a web application model in which a long-held HTTP request
allows a web server to push data to a browser, without the browser
explicitly requesting it. Comet is an umbrella term, encompassing
multiple techniques for achieving this interaction. All these methods
rely on features included by default in browsers, such as JavaScript,
rather than on non-default plugins. The Comet approach differs from
the original model of the web, in which a browser requests a complete
web page at a time.
Example of comet framework is APE. It is for javascript, however comet can be written not only in javascript.
The user establishes a WebSocket connection through a process known as the WebSocket handshake. This process starts with the user sending a regular HTTP request to the server. An Upgrade header is included in this request that informs the server that the user wishes to establish a WebSocket connection.
WebSocket URLs use the ws scheme. There is also wss for secure WebSocket connections which is the equivalent of HTTPS.
If the server supports the WebSocket protocol, it agrees to the upgrade and communicates this through an Upgrade header in the response.
Now that the handshake is complete the initial HTTP connection is replaced by a WebSocket connection that uses the same underlying TCP/IP connection. At this point either party can starting sending data.
With WebSockets you can transfer as much data as you like without incurring the overhead associated with traditional HTTP requests. Data is transferred through a WebSocket as messages, each of which consists of one or more frames containing the data you are sending (the payload). In order to ensure the message can be properly reconstructed when it reaches the client each frame is prefixed with 4-12 bytes of data about the payload. Using this frame-based messaging system helps to reduce the amount of non-payload data that is transferred, leading to significant reductions in latency.
Related
I need to develop a realtime notification system. Load won't be high, about a dozen of events per hour. But I just want to make it scalable for future development.
My application is written entirely in PHP.
I have found different ways of implementing real-time applications. And I think the following architecture is quite simple and have a lot of benefits.
But I want to use the Faye library for implementing real time notifications, because it has fallbacks, and generally I am not going to use Websockets because my load is really low, and at first I will stick to the long-polling mechanism. Faye provides a convenient way for disabling and enabling different transport protocols.
Here is how my architecture is going to look
However I have one question regarding communicating back from a client.
Consider the following case.
Client loads a page through plain old HTTP request to a PHP app
Client side script opens a websocket/long polling connection
Another person sends notification via posting it through a simple AJAX request
This notification is saved to a database and assigned to a target recipient.
Notification is posted to a Redis database and consumed by Faye
Notification is sent to a client, everything is fine.
So far so good, but I need to some sort of back communication, for example when a client dismisses an event.
How should this be implemented, should I send this action back using Faye or this should be sent directly to the PHP application. In case of sending an event back using Faye I need to notify my PHP application that an event was seen and dismissed. Of course I can use the same database from a Ruby application as used by PHP app, but this makes these two application coupled.
Could you suggest a right way to implement this ?
I have a project were I am required to add push notification for Cordova AngularJS Push Notification using PHP on server side which gives JSON array as output. I can implement chat etc using this, but I want to know how to implement it in push notification or accessing native app API. Firstly I thought using Javascript SetInterval, but it slow downs the app, and checks the API everytime...
For Cordova push notification you can take a look here:
http://phonegappro.com/tutorials/apache-cordova-phonegap-push-notification-tutorial-part-1/
Still, let's review some other methods of sending data to the client using Web APIs:
Long polling - keep the connection open on the server side with no or long timeout, and return a result when you want to send a push notification.
Use WebSockets - open a steady TCP connection to the server and transmit messages in both directions (unlike HTTP's request/response model).
Use PushManager - this is an experimental technology that is not yet supported on mobile devices, so I guess this is a no-go for you.
Use simple polling - every now and then poll the server for a new message.
Long polling and Web Sockets will overload the server if you'll have a lot of concurrently open connections, so I wouldn't go there. Also Web sockets are mostly used for communicating between clients (server passes the client info to both clients, then they can communicate on their own without the sever intermediating between them).
PushManager is too new a technology not yet supported in mobile.
For what you want (mobile I guess, as you want to use Cordova), and without knowing what you are actually trying to achieve, I would say go with #4. I understand you already tried it, but perhaps try to lower the polling rate to every 30 seconds or so.
I understand that while debugging it doesn't seem nice to send something from the server then wait the better part of a 30 seconds period until it appears on the client, but if you think of it from the user's view point you'll see that the user doesn't know when the server sends the data, so it does appear immediate.
However, if you're writing a chat client, then I would go with web-sockets, using the server to connect the two (or more) clients in the chat and letting them pass the messages directly. If you want the chat to be server backed, just periodically send the transcript to the server using simple AJAX.
DIY vs Hosted Realtime Data Stream Network Service
If you do not expect to have more than a few thousand clients using your app, the DIY (do it yourself) sockets technologies (WebSockets, Socket.io, etc) is feasible. Beyond a few thousand (many of our customers say in the range of 5 to 10 thousand) you will experience difficulty (and large expense on server resources and scalable code) scaling your service.
Using a hosted realtime data stream network service like PubNub, Pusher, Ably, etc will be less costly and complex and it will just work. With some of the hosted services (PubNub for sure - which I work for - full disclosure) provides the ability to publish the message in realtime and include a push payload (for GCM, APNS and MPNS) that will also send the push notification if the app is in the background or not running.
With PubNub BLOCKS, you can also implement server side code that runs in the PubNub Network to inspect, manipulate or process the message without having your server do the work. This means you could send the message to other third party services: translate message to another language, use AI services for whatever reason, send an SMS/email/etc and much much more.
I have a PHP app that needs to talk to a service which has a API that produces XML responses to HTTP requests. If this service was on a separate server I would normally use a HTTP client like Guzzle to create and consume, requests and responses.
But my service will be (for the time being) on the same server. In this scenario is making HTTP requests in this fashion still my best option? Will all my requests to the API leave the server which will add latency which could be avoided?
Yes - use Guzzle/HTTP. If you need to scale later you'll be able to take advantage of the network easily. Latency won't be an issue - the traffic won't leave the box.
I have the following scenario:
I have a given program which provides a JSON interface to which I can connect using a socket connection. Since I want to integrate that interface into my web-application, I'm trying to use the PHP sockets for the communication between server and client. The communication is bidirectional, which means my PHP client is sending requests to the server and the server is also sending requests to my PHP "client". I have no problems with the connection between my PHP and the JSON interface. The only problem is, since I have to wait for requests on the PHP side, I have to run it in an infinity loop. I want to 'echo' some responses and requests i get somewhere into my web-application without having that infinity loop.
My question is, is there a good way to create one php file which can:
create an own socket server so I can send stuff to it from my web application without being stuck in an infinity loop
the stuff I sent to it can be redirected to the JSON server
the response I get from my JSON server redirecting to my web application
Use case I have a solution for: I have a NFC card reader which provides me the functions and informations of a card (uniqueid) and it's connected to my network.
The JSON server sends me a request on "card detected" and I respond with "allowed" or "not allowed". (There the infinity loop doesn't matter)
Use case I don't have a solution for: I have my web application open and I want to write the "uniqueid" parameter into an input field to assign that card to a person. I want to do it this way:
- Click a button "assign card"
- Hold card over the card reader
- Write uniqueid into input field
I don't want to make a direct connection from the web application to the JSON server. I want to make a temporary connection from the web application to the PHP server which has a permanent connection to the JSON server.
I hope this is understandable.
Yes you can. Look into using Ratchet in your application. It seems to fit your requirements. It has bi-directional communication via Websockets.
Your browser will connect to a Ratchet based application in your server listening in a certain port and you will be able to send and receive messages using that connection.
The alternative is long-polling. You can learn more in this StackOverflow answer (which also features Websockets).
When it comes to building my web applications, I know HTTP 2 is going to be recommended for all traffic coming to the site. I understand the security concerns and the reason why it is recommended/forced to be used now.
When it comes the web-based languages I code in and understand such as Ruby, PHP, and Perl.
Is there any special functions that I will have to do to produce a secure connection to my server or all do we need to do is redirect all traffic to https:// over http://?
Basically, my autoloading class in PHP would load all classes and functions for my web application to operate. Would I need to create a SSL.class.php for allowing the connection to be secure within my PHP?
The changes in HTTP/2.0 over HTTP/1.1 are mostly relevant if your application streams large amounts of data to many simultaneous users.
Is there any special functions that I will have to do to produce a secure connection to my server or all do we need to do is redirect all traffic to https:// over http://?
No. HTTP/2.0 does not require TLS. If you want TLS (which, personally, I encourage), you still need to send clients to https://.
Basically, my autoloading class in PHP would load all classes and functions for my web application to operate. Would I need to create a SSL.class.php for allowing the connection to be secure within my PHP?
In most cases, the HTTP layer is a webserver problem, not a PHP-land application code problem.
If you are working on a framework that insists on parsing request headers and managing responses in a very HTTP-like fashion, then yes, you probably need to be aware of some of the changes in the new version of the protocol.
Differences Between HTTP/1.1 and HTTP/2.0 for Developers
Servers can push more data over an established connection in HTTP/2.0. This is really neat if you need to push real-time notifications (e.g. what StackOverflow does).
Better multiplexing and streaming; it's now possible to stream multiple resources over the same HTTP connection.
Source
Unless your application is keenly aware of networking protocols, it shouldn't matter much for our day-to-day CRUD interfaces.