So the way I see this happening in my head is that my game would make calls to my server and then my server would take care of sending whatever notifications required (ex:match is ready, friend requests).

This is the method for pull notifications, not push notifications. The difference being that with pull, any new notifications won't be received until your client next checks in with the server.

If you want to implement push notifications, you need to hold a long-lived connection to the server open, so that the server can immediately 'push' new notifications down to your application when. Popular ways to accomplish this include HTTP Long Polling, or WebSockets.

However, I'm not sure this is functionality worth building from scratch, as there are many relatively cheap off-the-shelf solutions. For example, AWS offers such a solution (full disclosure: I work on the AWS Mobile team).

If you want to implement push notifications, you need to hold a long-lived connection to the server open, so that the server can immediately 'push' new notifications down to your application

If this is on mobile, then Apple and Google already have push notification APIs that use the phone push system.

However, the question is then how to integrate this with the Unity code base.
For Apple, there appears to be a tutorial here: http://forum.unity3d.com/threads/ios-push-notification-tutorial.210142/
I imagine you can find the same for Google Play.

Note: You have to be a mobile developer for this to work, and that will cost some money.
Also, the APN servers (on the Apple side) require that you have a long-lived TLS connection to the servers, to send pushes over, which you cannot create entirely in PHP; you need the ability to run a long-lived service on your server.

Each of the major OSes has a corresponding API and server infrastructure to deal with this. Each one of them requires you making a corresponding native plugin for Unity and a web service.

The process I'm aware of works like this:

- Your device calls an API which "registers" the device (which gives you a unique ID for your device). This is where you do your native Unity plugin programming.
- You record that ID on your servers, associated with whatever ID you're using to identify your players.

- When a second player wants to send a notification to a user, they send a request to your server.
- Your server maps the player ID to the device ID(s) that that player has registered with, then contacts the Apple/Google/Amazon/Microsoft notification service to send the message through.
- The receiving device uses the OS's own polling mechanism to receive the notification.

- The user taps on the notification, which can then launch your app with whatever metadata came along with the notification. This is another place where you may need some native code to retrieve that metadata.

Also, the APN servers (on the Apple side) require that you have a long-lived TLS connection to the servers, to send pushes over, which you cannot create entirely in PHP; you need the ability to run a long-lived service on your server.

That's one of the advantages of the AWS solution - no need to maintain the long lived connection from your own server. Your PHP server just invokes SNS when it has messages to deliver.

Ok, thanks for the explanations everyone, definitely helped me understand a lot better. I think I will start by reading looking up AWS. The prices are a lot lower than I thought they would be.

Also, the APN servers (on the Apple side) require that you have a long-lived TLS connection to the servers, to send pushes over, which you cannot create entirely in PHP; you need the ability to run a long-lived service on your server.

That's one of the advantages of the AWS solution - no need to maintain the long lived connection from your own server. Your PHP server just invokes SNS when it has messages to deliver.

Ok, so i took a look at it, and played with the sample. Was able to send a message from inside the aws console. But now I am trying to wrap my head around what to do next.

Can i now have my server handle the push notifications, meaning, my server handles the calls to the aws services after a user contacts it? Would it be possible to have a checklist of what needs to be done or what I need to keep track of?

my server handles the calls to the aws services after a user contacts it?

Yes.

a checklist of what needs to be done

The Amazon documentation is reasonable.

Perfect, thanks.