Develop Reference

For a push notification, is a websocket mandatory?

I have PHP on the server side, and HTML and javascript on the client side.
I am making an app where a stakeholder types a message that is broadcasted to multiple recievers of a group in real time.
I did some research on google and I understand I need to use WebSockets or Comet for real time push notifications. Is WebSocket or Comet mandatory for sending mass notifications to users?
Is my understanding correct? Any references to start with?

If the client is a browser, then the ONLY two ways a standard browser can connect to a server is via an Ajax (e.g. http) request or a webSocket connection. So, if you want a client to get notified of something from the outside world it has to use one of those two mechanisms.
HTTP requests are transitory. The client makes a request of a server, the server responds. HTTP requests are perfect for the client requesting information from the server. They are not very good at the server sending information to the client because normally the client is not connected. There are hacks and work-arounds where the client "polls" the server on some interval and maybe even the server uses longer running requests to try to simulate a "push" type system, but they are sub-optimal hacks at best.
webSockets are continuous connections. The client connects and the connection remains in place for as long as both sides want. This allows either side the ability to send a message to the other side whenever they want. That means the server can "push" data to the client whenever it wants. webSockets are efficient for push connections and are recommended (this is one of the main things they were designed for).
Comet is a library that was originally built for using HTTP to try to "hack" or "simulate" push before webSockets were invented and then before they were widely supported. I can think of no reason why one would want to use Comet instead of a webSocket unless you had such an old browser that webSocket was not supported.
So, if you are trying to do "realtime server push" to a browser, then you must have a continuously connected socket from the client which means webSocket (or something built on top of webSocket like socket.io).
For phone apps where you have access to the phone SDK, you can use the "push" system built into the OS to push some messages from server to client. This isn't quite the same as the two way webSocket channel, but since you asked about "push notifications", the OS push services available in both Android and IOS could also be an option for pushing notifications from server to client. Here's info on iOS notifications and Google Cloud Messaging
As of 2016, one can also use Server-sent events in all modern browsers except Microsoft browsers (not supported yet in Edge or IE) to push data from server to client. Here's a browser compatibility table. Server-sent events use a long lasting HTTP connection, a special MIME type and a supporting client in order to be able to send events from server to client at any time. Unlike webSockets, server-sent events are one way only (from server to client). A client would then use a traditional Ajax call in order to be able to send data to a server (whereas with a webSocket data can be sent either way over the same webSocket connection).
Here's a good description of how server-sent events work: How do server-sent events actually work?

Is your client application a SPA? (Single Page application)?
It's very important because if not, you have to consider that everytime a client change page, connection with websocket server will be lost.
In this case you have to manage a queue because if stakeholder send a multicast request when one client is disconnected, client won't receive nothing.
Polling won't solve this situation too and it's an orrible solution because mobile clients (for example) with typical internet plan, will consume megabytes for unuseful "ping" traffic.
A real example of polling is a child in a car asking his dad every minute if they are arrived to a destination!
So, Is there a solution without using spa?
Yes, using a "shared storage" between stakeholder and clients, and using websocket only for "wake up" online clients saying: Hey there is something new, go to check!
Everytime a client open a page it will receive from backend also not-read notifications, taken from the storage.
When a stakeholder want to notify something, it will just store the notification message in the shared storage and send a "pulse" to notification server.
Notification server will forward the "pulse" to online clients (just in case someone is stuck reading a page).
If a "pulse" is lost because a client is changing page there is no problem because the client will bring notifications from the storage.
Every page will contain this logic:
Retrive number or unread notifications (server side)
Connect to the notification server after 5 seconds (javascript side).
Hope it helps.

I would suggest that using webSockets is a more efficient way compared to other options, why is this? Well when a client receives a notification that there's a change in the server there is no need to create an AJAX call to the server to get that change, it can be sent to the client with the same webSocket connection more easily than AJAX. This means efficient code and a faster running App!

Socket.io - Socket connection between clients

Im looking form something to make socket connection between client, without pass through the server. Is there any node package to do this?. Server only send the other client socket, and the clients recieve and send data to each other..
Or, how can we make the implamantation. We need to make a server in client side, but we dont have node installed in the client..

The closest thing that currently exists in some form is not currently part of socket.io. It is called WebRTC and is implemented in Chrome currently. It allows the browser to connect with other browsers.
http://www.webrtc.org

The question is what kind of application is your client? If you are talking about ordinary webbrowsers you need to think about writing pluings (tough case).
If you are talking about clients you have more control then you should look at technique Puching the hole exploited by Skype or P2P apps.
http://it.slashdot.org/story/06/12/15/191205/how-skype-punches-holes-in-firewalls
In general the server is used for TCP sockets orchestration the acutall comunication go directly.

Is it bad to use socket.io for most of the requests or should I only use it to push data to client?

Is it bad to replace AJAX routes (called with $.Ajax from jquery) such as:
GET /animals
GET /animals/[id]
POST /animals
With socket.io events (event binded on client and server so the client can have a response):
emit("animals:read")
emit("animals:read", {id:asdasd})
emit("animals:write", animalData)
or should I "only" use socket.io it to push data to client?
[EDIT]
I could see one problem if I don't use socket io for my POST route. The problem is that I can't easely use the client's socket to broadcast data:
Server:
on("animals:write", function(data){
saveAnimal(req.data)
socket.broadcast(...)
emit("animals:write", writenAnimal)
})
VS
app.post(function(req,res){
saveAnimal(data)
// cant broadcast :(
res.send(201,writenAnimal)
})
I will push data to clients in some other requests for sure, so all clients will have at least 1 socket.

IMHO socket.io should be used if you want real-time data provided for your website. Take for example Stackoverflow. It uses websocket to update in realtime your scores and update your notifications.
But if you really want to create application that is SEO-friendly ( I mean supporting http for serving your pages ) and more important if you are aware of the difficulties in managing sessions and permissions in socket.io, I think you'll prefer AJAX for your pages and socket.io for other realtime data.

I would use ajax for this, its http based data requests, nothing realtime.

If you don't want to push data to the client, I don't see why you would use socket.io instead of AJAX. I mean with AJAX you don't need to handle a session with the client and it would probably scaled better.
With socket.io, for every connected client you need some sort of object on the server paired up with that one client. It will use more memory on the server for no reason if permanent connections are unnecessary or unwanted.
Also, AJAX will be better if you want to re-use your code with other systems, it is working with a huge existing ecosystem of tools.
That being said, if you need WebSocket features like pushing the data to the client or doing some kind of broadcast, you might consider using socket.io instead of AJAX since it will be hard to achieve this with AJAX and socket.io offers those features.

Javascript remote events?

Is it possible to have a web service notify web clients when something occurs via HTTP request/response? Right now my client has to poll the server using HTTP Requests at an interval to check for updates, but it would be far more convenient if I could register a javascript function to the server from my client and have it be simply called when server state changes.
Note that the web service is written in Python and utilizes HTTP APIs (I think it uses cherrypy, if that's relevant).
If this is possible could someone point me to some tutorial that explains how to do this or give me a basic understanding of how this can be accomplished?

Look into Comet

You can't start a request from the server to the client. You can only poll the server (which you did), use a hidden iframe, use a plugin, or use the new HTML5 WebSockets which allows the server to send a message to the client.

If you are into Node.JS, look into socket.io and hook.io
https://github.com/hookio
https://socket.io

Persistent connection with client

Is there a general way to implement part of an application with JavaScript and supplying a persistent connection to a server? I need the server to be able to push data to the client, regardless of the client being behind a firewall. Thanks in advance

See Comet - it's like ajax, but it holds a connection open so the server can push information to the client.
Note that compliant browsers will only hold 2 connections (note: most modern browsers no longer comply) to a particular domain (by default), so you might want to split your domains (e.g. www.yourdomain.com and comet.yourdomain.com) so that you don't drastically slow down the loading of your pages. Or you could just make sure you don't open the comet connection until everything else is loaded. It's just something to be careful of.

You should look into Comet:
http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications

With HTTP, the connection has to start from the client. But there are techniques available for having the server hold the connection open and flush data as needed.
These are generally considered to be Comet or HTTP Streaming architectures.

You can use Comet programming techniques for this. Basically the page makes a call to the server that doesn't return until the server has something to send (at which point the client immediately makes the same call). This way the server can push content to the client pretty much whenever it wants.
Support varies depending on platform and is more an issue with the server than the client.

Here are a few questions in a similar vein. And of course all the questions tagged comet
Implementing a self resetting XMLHttpRequest object
Server-side Push in Rails
Is there an alternative of ajax that does not require polling without server side modifications?
Long-lived connections (asynchronous server push) with Apache/PHP/Javascript?