Develop Reference

Real time client information synchronization, best practices and advice

I am writing a PHP backend, JS/Jquery front end application that will allow users to "communicate" in near real time. That is the hope at least, my question is what is my best course of action? Am I best to use WebSockets to send data between the server and client or would use AJAX and some sort of timer (x amount of seconds) be better. My worry with the AJAX way is that it may be taxing on the server to have 10+ clients all asking for data every 15-30 seconds. I need it to be near real-time and so 5 minutes is not really realistic.
An example of what I am trying to do would be if I had 5 users all on a page and user 1 updates their status, I would want users 2,3,4, and 5 to see the update as fast as possible without having to refresh.
I am mixed on what I think is best and I don't want to start doing it one way and find out it is insecure or terrible after getting halfway done. What is my best route with an application like this?

Here's a list of popular possible solutions:
Short polling (what you're referring to in AJAX
Long Polling (AJAX too, but not too many requests)
Websockets
WebRTC
So, for short polling as you've said it consumes lots of resources so let's remove that from the list.
as for long polling, its idea is that a request is send to server and the server doesn't respond unless a new event has happened (keeps the request) but its rarely used in modern development. so If you're going to work with other developers its kind of bad decision.
for WebRTC, browser compatibility is not that great and still a draft in W3C.
Thus, you're left out with WebSockets, and yes they consume ram but not CPU. ram is much cheaper (and it doesn't consume that much too).
As for security they can be considered equal (except for WebRTC which is better because it is actually P2P Communication)
Side note: don't overthink it :)
Here's some resources that can help you:
https://webrtc.org/
https://github.com/walkor/phpsocket.io //Socket library for PHP similar to Socket.io
https://socket.io
What are the realtime communication protocols available for the web? List of the protocols
https://codeburst.io/polling-vs-sse-vs-websocket-how-to-choose-the-right-one-1859e4e13bd9 great article for polling, websockets & covers SSE too

there is one way to make the RTC, RealTime App, Just Use the Socket.io "WebSocket " for signaling and before that take a full view of these webPages:
https://bloggeek.me/
https://www.html5rocks.com/en/tutorials/webrtc
https://w3c.github.io/webrtc-pc/#rtcsignalingstate-enum
https://www.w3.org/TR/mediacapture-streams/#legacy-interface-extensions
and i start to development this technology with this book enter link description here it will open your view of RTC usage and All Details.

Node.js chat without Socket.IO

I just started learning Node.js and as I was learning about the fs.watchFile() method, I was wondering if a chat website could be efficiently built with it (and fs.writeFile()), against for example Socket.IO which is stable, but I believe not 100% stable (several fallbacks, including flash).
Using fs.watchFile could perhaps also be used to keep histories of the chats quite simply (as JSON would be used on the spot).
The chat files could be formatted in JSON in such a way that only the last chatter's message is brought up to the DOM (or whatever to make it efficient to 'fetch' messages when the file gets updated).
I haven't tried it yet as I still need to learn more about Node, and even more to be able to compare it with Socket.IO, but what's your opinion about it? Could it be an efficient/stable way of doing chats?

fs.watchFile() can be used to watch changes to the file in the local filesystem (on the server). This will not solve your need to update all clients chat messages in their browsers. You'll still need web sockets, AJAX or Flash for that (or socket.io, which handles all of those).
What you could typically do in the client is to try to use Web Sockets. If browser does not support them, try to use XMLHttpRequest. If that fails, fallback to Flash. It's a lot of programming to do, and it has to be handled by node.js server as well. Socket.io does that for you.
Also, socket.io is pretty stable. Fallback to Flash is not due to it's instability but due to lack of browser support for better solutions (like Web Sockets).

Storing chat files in flatfile JSON is not a good idea, because if you are going to manipulating the files, you would have to parse and serialize entire JSON objects, which would become very slow as the size of the JSON object increased. The watch methods for the filesystem module also don't work on all operating systems.
You also can't compare Node.js to Socket.IO because they are entirely different things. Socket.IO is a Node module for realtime transport between the browser and the server. What you need is dependent on what you're doing. If you need chat history, then you should be using a database such as MongoDB or MySQL. Watching files for changes is not an efficient way and you should just send messages as they received.
In conclusion no, using fs.watchFile() and fs.writeFile() is a very bad idea, because race conditions would occur due to concurrent file writes, besides that fs.watchFile() uses polling to check if a file has changed. You should instead use Socket.IO and push messages to other clients / store them in a database as they are received.

You can use long pooling method using javascript setTimeout and setInterval
long pooling
basically long pooling working on Ajax reqest and server responce time.
server will respond after a certain time (like after 50 seconds ) if there is not notification or message else it will respond with data and from client side when client gets response client javascript makes another request for new update and wait till response this process is endless until server is running

Advice on which technology to use for real time notifications

I have X amount of activity sensors connected to a server that inserts data to a database everytime a sensor is triggered. What I'm trying to do is create a web interface with a blue print of the facility (svg) and whenever a sensor is triggered, besides the db insert, I want it to show some sort of alert in my blue print. For that I need to keep an open connection to the server I think.
I was thinking of using web sockets, but it might be overkill since I only need to retrieve data from the server. But running an ajax call every second doesn't sound very efficient either. Are there any other alternatives?
Thank you

Some potential choices include:
WebSocket
Adobe® Flash® Socket
AJAX long polling
AJAX multipart streaming
Forever Iframe
JSONP Polling
Which actual transport you end up using will depend on the your requirements for browser support and what technology you are using on the server to handle these requests. The transport choice may also depend on your network topology - what types of load balancers you need to integrate with, proxies, etc.
There are many libraries available on both the client and server sides, many of which support more than one of these transports.
For example (not an exhaustive list):
socket.io for nodejs
WebSocket
Adobe® Flash® Socket
AJAX long polling
AJAX multipart streaming
Forever Iframe
JSONP Polling
SignalR for an asp/.net backend
WebSockets
Server-Sent Events
ForeverFrame
Long Polling
Atmosphere for a java backend
WebSockets
Server Side Events (SSE)
Long-Polling
Forever frame
JSONP
IMO - Websockets is NOT overkill for this type of problem and would lend itself nicely to this type of application.

Without specifically discussing frameworks or knowing what is running in the backend of your server(s), we have a few options to consider for the frontend:
Websockets
Websockets are designed for bidirectional communication, although it is kind of shocking how many users are surfing the web in a browser that doesn't support websockets. I always recommend a fallback for this, such as the other methods listed below.
SSE
SSE is an HTML5 spec and is still shaky at best. Try scrolling on a page while when an SSE event fires... It may be a little easier on the backend, put it sometimes hangs on the client side since it runs inside the same thread that the DOM is running in.
Long Polling
Keeps your connection open. It doesn't scale well with PHP, but performs swimmingly with Python+Twisted on the backend, or Node.Js
Good Old Ajax
Keep your requests small, and you still have a scalable solution. Yes, a full GET request is the most expensive, but is supported in just about every browser rolled out the past ten years. It is also worth noting that GET requests are easy to scale horizontally with more hardware.
In a perfect world:
You would break up your application into a few components, operating behind a reverse proxy such as Nginx. Then use Node.Js + Socket.IO handle the realtime aspects of your app.
Another option would be to use small Ajax requests, and offer websocket support for the browsers that support it. This is advice specifically for PHP in the backend.

WebSocket is certainly not overkill. On the contrary. With websockets, you have a bi-directional communication channel; this means, that the server can initiate communication whenever it seems fit (e.g. when sensor data changes).
In a previous project, I have used node.js together with socket.io, to monitor 50+ sensors. Data was updated in real-time in a browser. The data was visualized using smoothie.js.
Whenever a sensor value was updated, it was communicated to the browser. Some sensors only updated once a minute, others once a second, ...
Polling would have been overkill, because it would retrieve all data for all sensors, even from those that were not updated yet.

I had a similar problem and did a lot of research on this. As I understand it, there are three main options:
Short polling: Have an endpoint that your javascript client pings every second. This is the worst option, because the pings add latency up to one second to your communication, and depending on how you implement, the endpoint could query the database every second, adding unnecessary overhead.
Long polling: Have an endpoint that your javascript client pings that holds the connection until a) the event occurs or b) the connection times out. If the endpoint returns a response, the client gets the event information. If the endpoint does not return a response, no event has occurred, and the client sends a new request. This is a good option because the events can immediately trigger the response to the client, assuming you have an asynchronous interprocess communication layer (like 0MQ) to send the message without any sort of polling.
Websocket: Have your javascript client connect to a websocket server, which will send a message to your client immediately upon the event trigger.
I think a websocket is your best option, because it accommodates immediate communication of the event without all the request/response overhead. And most importantly, this is exactly what websockets are designed to do! As such, you will probably have to write the least amount of custom code with this solution.

There are two great commercial services that might work for you.
Firebase - a javascript hierarchical database and realtime
messaging/ synchronization platform, uses websockets and has other fallbacks
PubNub - a real time message passing and queue system, uses websockets

If I wanted to create an AJAX chat what communication technique should be used to maintain scalability?

I put together an AJAX chat a while back ASP.NET MVC and jQuery. The javascript would hit the server about every 7 seconds to check for new messages. Obviously this was horrible on performance as the chat grew and included more and more users. The site traffic grew exponentially with so many requests going on. A user could leave the computer on all day and not even be there and they would still be making hits every 7 seconds.
Is there a better way to do this? I have heard of something called "push" but I haven't really been able to wrap my head around it. I think I just need pointed in the right direction.
1.) What is the best way to develop an AJAX chat and have it be scalable?
2.) What is push and how would I just that with jQuery?

1.) What is the best way to develop an AJAX chat and have it be scalable?
I agree with #freakish about the complexity and potential lack of scaling of IIS.
However, there is a relatively new Microsoft option in the works called SignalR which could become a core part of ASP.NET. More details in this related SO Question:
AJAX Comet - Is there any solution Microsoft is working on or supports to allow it to be scalable?
2.) What is push and how would I just that with jQuery?
Partially answered elsewhere, but it's a long-held persistent connection between the server and the client which means the server can instantly 'push' data to the client when it has new data available.
jQuery does support making AJAX requests but the core library doesn't support expose ways of doing HTTP Long-Polling or HTTP Streaming. More information in this SO answer to 'Long Polling/HTTP Streaming General Questions'.

Server push is a technology that allows the server to push data back to the client without forcing client to make many requests (like every 7 seconds). It is not really a matter of javascript but rather good server scripting. The upcoming HTML5 will make it simple due to server-sent events and/or WebSockets. This will be a true TCP connection between different machines.
But if you intend to make a webpage compatible with older browsers, then the most common technique is the long polling. The client sends request to the server and the server does not respond to it until it has new data. If it does then the response is made and the client immediatly after receiving data calls the server with new request. In practice however this requires the server to be well-written (for example it has to maintain thousands of idle requests at the same time) and can become a rather big challenge for developers.
I hope this helps. :) Good luck!

The technique you should use is the real-time persistent long running connections over a web page using WebSockets. You can use this library.

Node.js is becoming quite popular to build something like this and supports socket connections so you could push the data out only when there is a new message. But that would be learning something completely new.
Another nice potential would be to use MVC's OutputCacheAttribute and use the SQL dependency option so your AJAX page could be cached and would only be a new request when a new chat message appears. Also you would want your controller to be an Asynchronous controller to help reduce the load on IIS.
Enjoy, optimization is always fun and very time consuming!

webgame with simultaneous players

I have seen many webbrowser based games with players playing simultaneously.
Usually after waiting some time you can join a room where everyone is playing or you can play against one other player.
All those games use Flash.
How they achieve that?
It would be very complex to accomplice without Flash?
There are any toolkit (rails, etc) or plugin that provides this functionality?
Or it is just a matter of storing sessions and mixing them ?
Just a quick edit:
I am not interested in Flash or Silverlight solutions

There are a couple options for a JavaScript-only solution. They all involve AJAX of one form or another. (See my answer on AJAX and Client-Server Architecture with JavaScript for a larger breakdown.)
You have a choice between AJAX Polling, Long Polling, COMET, or the upcoming Web Sockets. The first step is to understand AJAX. Once you are comfortable with it, you can setup a polling system (with setInterval) to poll the server for new data every n miliseconds.

It's possible to do it without flash if you're comfortable with ajax and your game doesn't require rapid interactions between users. But in either case, I believe you have to poll the server. You might also want to read about comet http://en.wikipedia.org/wiki/Comet_(programming)).

Can you clarify what kind of game you would like to make? Turn based or real-time?
Since you're not interested in flash or silverlight solutions (which can use sockets and thus scale well with thousands of users) you can use javascript and use ajax to send and receive data.
Essentially you can use ajax like a socket by sending out input then letting the script "long poll" the server by having the server delay responding to it until it has data to send. The only problem is that you can only keep a connection open for so long before it times out (~30 seconds). This isn't usually a problem though since you're passing data back and forth frequently.
I'd research fastCGI (or so I believe it can work like this) and have a game server daemon respond to the requests directly. That way it can open a single database connection and process all of the clients quickly. While this isn't necessary it would probably scale really well if implemented correctly.
At the moment I've been making a proof of concept that's kind of naive. (Less naive than using the database as state and just using PHP scripts to update and receive the database's state. I should note though that for a only a few users and your own database this works rather well. I had 20 clients walking around at 100 ms updates. Sure it doesn't scale well and kills the database with 10 connections per client per second but it "works"). Basically the idea is that I have javascript generate packets and sends them to a PHP script. That PHP script opens a unix domain socket and forwards the data to a C++ daemon. Haven't benchmarked it though, so it's hard to tell how well it'll scale.
If you feel comfortable though I really do recommend learning flash and socket networking. Using Epoll on linux or IOCP on windows you can host hundreds of clients. I've done tests of 100 clients on a C# socket server in the past and it took less than 5% CPU handling constant streams of small packets.

Depends what technology you want to use. Flash can be used to create a game like that, so can Silverlight. They both use javascript to send mouse movements and other user input asynchronously to the server so that the game state can be updated on the server.
An article of flash game development:
http://www.brighthub.com/internet/web-development/articles/11010.aspx
Silverlight:
http://www.brighthub.com/internet/web-development/articles/14494.aspx

Java Applets are able to communicate with JavaScript (e.g. you want your UI to be HTML&CSS). So in theory you could implement your network code in a signed Java Applet. In this case you would not be limited to the plain client-server model.