Develop Reference

Can I use Push API to send a notification to a phone if they are in the same LAN without internet connection?

I like to develop a web app for mobile devices (Android) that will be served by a local server. The server should be able to send push notifications to the phones via the Push API.
The setup will have no connection to the internet and I can't find a note if the explained setup needs to connect to some cloud service in order to send the push notifications.

mmm I'm afraid you can't, each browser vendor subscribe the serviceWorkers to its own Message Server (Chrome: fcm.googleapi.com, Firefox: updates.push.services.mozilla.com, etc.), so it is something we don't have control over...
Although technically there's a solution, it would require you to sort of "hack" your network, namelly, it would require a Man In The Middle attack. You would have to code a program to redirect all your network traffic to that program (probably using raw sockets, and sending ARP packets), and then make that program listen for request to those Message Servers (those request will be over HTTPS - port 443), then your program has to send exactly the same response the real Message Server would send. It's is not an easy task.... but it is the only solution I cant think of.
Note: Your browser will block any serviceWorker registration that is not over a "secure connection", that means that your server MUST be serving request over HTTPS or you could install your web app locally on your users devices (so that they can be accessed by "localhost").

#Mounica: May be I am a bit late, but just posting my answer in case it is helpful to you or others coming on this page. Your scenario can be addressed using MQTT Protocol within the Wi-Fi network. You will have to set up an MQTT Broker within the network and Make an MQTT Client in your iOs App. You can subscribe the MQTT Client to the MQTT broker on a topic same as GCM works and use MQTT Broker to send Push Notification to topics subscribed by MQTT Clients.
MQTT with Android Applications

How does a push server know where to send its notification to

When I receive a notification on my phone, how was the push server able to communicate with the device?
Is there a constant connection between client and server? As far as I know something like WebSockets will put a huge load on the server side with all these devices.
Is it some kind of polling mechanism by the client? Seems still like a huge load of requests.
Does the client keep the server up to date with his IP address? How comes no firewall blocks this request (like the one of the router when using Wifi)?
Thanks!

Push notification for iOS and Android are services from Apple (APN) and Google (Cloud Messaging) respectively. For example for APN, the server sends the message to Apple's APN server, including a token that identifies the device. In fact the token is unique for your app running on a device. Obviously the channel is secure and your server need credentials (certificate).

How to address a specific android phone to send push notifications

I wanted to know how to address a specific android phone to send push notifications as the google's gcm is slow and also as i want to learn how to send push notifications without google cloud messaging and to build my own api for sending push notifications to other platform devices .
I'm not sure how to address an android phone whether by its IP address or keep a socket for listening at a port.
Please help!

You not need to use ports or some listening mechanism to build. Use the Google's GCM way.
You need to build a service that will periodically check your server for any massages to get (fetch) for your specific device (keep a self created unique id with each device and registered the device on your the server by that id). Actually this is not pushing. but this is what happening in the GCM server also. When you put some massage for some specific device to your server(it is the pushing) the device will grab that by the service running on it.
simply you have to create a server by yourself (like GCM server)
Then you have to create a service to run on mobile to check updates on your server (like android play service)

Protocol used for sending push notification in Android

I want to know which protocol is used to send push notification to android devices and which to send push notification requests to GCM.
Whether it is HTTP, HTTPS or some thing else?

The protocols of the communication between the 3rd party server and GCM server (HTTP or XMPP) were already mentioned in the other answers.
The protocol of the communication between the device and GCM server is not discussed in the GCM documentation, since you never have to access it directly as an Android application developer, and therefore you don't need to know about it.
However, here's a quote from a Google developer from the team that created GCM, which says a few things about the connection. From what he says, you can only know that it's a long-lived TCP connection.
GCM maintains a long-lived connection - and reconnects if it knows the
connection was broken. A router/AP/NAT is supposed to send a FIN or
RST to terminate the TCP connection - so GCM and servers will know the
connection is dead.
However a number of routers and mobile operators don't do this, and
then GCM needs to rely on the heartbeat, ~15 min on Wifi, more on
mobile.
(The quote is taken from an answer by that person)

There are two protocols http and xmpp which you can use to send message to GCM server.
Now its up to you what you want to use. If you want to broadcast message then u should go with http.
you can broadcast 1000 message in a single http request. And only one message through xmpp in a request...
Http can be used only for down streaming(3rd party app server -gcm-mob device)
But gcm won't support up streaming using http.
for that you should use xmpp.Xmpp can be used for both up streamlining and down streaming.
Implementaction of push notification can be very easy if you are going with http and that much more hard if you are going with xmpp.but Google has provided detail tutorial how to implement xmpp.
So please have a look On Google developer site.

Looking at #user3523641's answer and further conversation, I'll try to explain further:
The way of delivering messages is based on the protocol that you've chosen, either HTTP or XMPP (i.e., it's the same). The magic and basic way of working is leaving a socket opened between the GCM server and the user's device.
This way, when an user should receive a message, this opened socket will be used and send the message through itself. This also helps the GCM server knowing which devices are connected or not. So this way, if your third party server says a message should be sent to a user and the GCM server knows the user is not connected, it won't send it at that time, but will try once the connection is again established, so it won't waste connection attempts in vain. The default timeout is 4 weeks, however, it can be changed.
As per the official GCM documentation:
If the device is not connected to GCM, the message will be stored until a connection is established (again respecting the collapse key rules). When a connection is established, GCM will deliver all pending messages to the device, regardless of the delay_while_idle flag. If the device never gets connected again (for instance, if it was factory reset), the message will eventually time out and be discarded from GCM storage. The default timeout is 4 weeks, unless the time_to_live flag is set.
Finally, when GCM attempts to deliver a message to the device and the application was uninstalled, GCM will discard that message right away and invalidate the registration ID. Future attempts to send a message to that device will get a NotRegistered error. See How Unregistration Works for more information.
You can find more info here.

It uses both HTTP and XMPP
When the message is processed successfully, the HTTP response has a 200 status and the body contains more information about the status of the message (including possible errors). When the request is rejected, the HTTP response contains a non-200 status code (such as 400, 401, or 503).
iOS however, requires a dedicated TCP connection on a proprietary port, and GAE environment doesn't allow any external protocol except HTTP over port 80.
The message size limit is 1024 bytes.
Google limits the number of messages a sender sends in aggregate, and the number of messages a sender sends to a specific device
This is how these components interact:
Google-provided GCM Connection Servers take messages from a 3rd-party application server and send these messages to a GCM-enabled Android application (the "client app") running on a device. Currently Google provides connection servers for HTTP and XMPP.
The 3rd-Party Application Server is a component that you implement to work with your chosen GCM connection server(s). App servers send messages to a GCM connection server; the connection server enqueues and stores the message, and then sends it to the device when the device is online. For more information, see Implementing GCM Server.
The Client App is a GCM-enabled Android application running on a device. To receive GCM messages, this app must register with GCM and get a registration ID. If you are using the XMPP (CCS) connection server, the client app can send "upstream" messages back to the connection server. For more information on how to implement the client app, see Implementing GCM Client.
Check out this for more details -->
Google Cloud Messaging for Android (GCM)
Android Cloud to Device Messaging Framework
Cloud Messaging
Cloud to Device Messaging

Android Cloud to Device Messaging without google account

Is it true that if a user does not have Cloud to Device Messaging (C2DM) in his account the C2DM will not work?
If so, how can I do push notifications without a Google account?

The different techniques to send push notifications can be listed as follows
Android Cloud to Device Messaging (C2DM) on OS2.2+
Other techniques for pre OS2.2 Devices.
Cloud to Device Messaging (C2DM) OS2.2+: The standard push notification method used in the android platform is called Android Cloud to Device Messaging (C2DM). The service provides a simple, lightweight mechanism that a server can use to tell an app to contact the server directly, to fetch updated data.
C2DM allows to send lightweight messages to android apps. The messaging service is not designed for sending a lot of user content via the messages. Rather, it should be used to tell the apps that there is new alert on the server, so that the application can fetch it.
C2DM limitations:
The message size limit is 1024 bytes.
Google limits the number of messages a sender sends in aggregate, and the number of messages a sender sends to a specific device
C2DM makes no guarantees about delivery or the order of messages
C2DM requires users to set up their Google account on their mobile devices.
C2DM requires devices running Android 2.2 or higher that also have the Market application installed
Server should be
Able to use HTTPS to communicate with C2DM Server.
Able to communicate with our client.
Able to fire off HTTP requests to the C2DM server.
Able to handle requests and queue data as needed. For example, it should be able to perform exponential back off.
Able to store the ClientLogin Auth token and client registration IDs. The ClientLogin Auth token is included in the header of POST requests that send messages. For more discussion of this topic, see ClientLogin for Installed Applications. The server should store the token and have a policy to refresh it periodically.
Other techniques for pre OS2.2 Devices:
Poll rather than push
SMS
Persistent TCP/IP
Third-party offerings
Poll rather than push: Android app can periodically poll the server for new messages from a background local service. The more often you poll the closer you get to the real-time push.
Adv: Easy to implement.
Disadv: Not real-time.Will kill the battery.
SMS: Android apps can intercept text messages in the android phone.So if a server can send an sms when there is a notification, the android app can receive the sms and then check for new data at server.
Adv: easy to implement. Fully real-time updates.
Disadv: Can be costly to do.
Ericsson labs provide a hosted service which allows upto 2000Sms's to be sent.
Persistent TCP/IP: The android app initiates a long-lived mostly idle TCP/IP connection with the server and maintains it by occasionally sending keepalive messages. Whenever there is something new on the server, it sends a messages to the phone over the TCP connection.
Adv: Fully real-time updates.
Disadv: Hard to implement a reliable service on both the phone and the server side. The Android OS is known to be able to kill services when it’s running low on memory, so our notifications service can easily disappear. What happens when our phone goes to sleep? Imagine if all the apps use the same technique . there will be plenty of open connetions which will drain the battery.
Third-party offerings
Urban Airship Push : The big disadvantage is that it requires the user install the AirMail app onto their device.
The deacon project
xtify
pushdroid.org