19Apr/1016
Welcome to The Deacon Project!
What's Deacon?
Deacon is a push notification library for Android and Java applications. It uses the flexible Meteor web server to deliver notifications using comet technology. For more information, check out the About Page. You can also learn how we got started, or visit our repository on GitHub.
Why should I use it?
There are commercial services that offer push on Android, and Google began supporting "cloud to device messaging" in Android 2.2. If you want to run your push notifications through your server, support earlier versions of Android, or use push in your pure Java app, Deacon is for you.
July 3rd, 2010 - 10:43
Just stumbled upon this project and from what I have read so far, it looks like it could become very popular. Few questions:
1. Does Deacon run as a service on Android? i.e. will it receive notifications even if the app is not running? if not, can it be run as a service?
2. How many unique channels can you have? i.e. is the usecase such that every phone can have its own channel? If not and everyone has to share the same channel, then everyone gets every notification sent to every other phone using your notifications. This could result in your phone never going to sleep on a busy notification platform.
3. Does each channel keep a socket open on the Meteor server? Does this not cause file/socket limits to be reached on the server pretty quickly?
July 3rd, 2010 - 11:45
Hi Sunvir – Please see the reply to these questions on the Deacon-Talk mailing list: http://lists.angryhosting.com/pipermail/deacon.talk/2010-July/000009.html
August 27th, 2010 - 09:55
I’m gonna give this a go as well. Building an Android application that will need stable push messaging for lots of users. At the moment I’m using MQTT, but am looking at new options. Thank you.
January 8th, 2011 - 07:55
The Deacon project description says it uses the Meteor web server. Can it be configured to use any other web server? For instance, the OC4J application server?
January 8th, 2011 - 19:43
Deacon is only set up to work with Meteor, but we are currently working to factor the transport protocol out of the main Deacon service class so that it can be easily replaced with a connection to another server. Keep an eye on the git commits and let me know if you’re interested in helping to add support for a new server.
September 30th, 2011 - 06:03
looks good, but I dont know much about setting up a Meteor web server and how to make it push messages. And I guess you also need to make some registration of each device on the server?
September 30th, 2011 - 08:09
Meteor server is relatively easy to set up; instructions are at: http://meteorserver.org/installation/
To send push messages, you simply telnet into your configured controller port on the server and issue commands according to: http://meteorserver.org/server-docs/
Registration of devices with the server is not required. You simply need to know the channel name that you wish to subscribe to. Channel names are dynamic, created whenever a subscriber connects or an event controller sends a push to a given channel. You can use a channel-per-device (in which case your event controller needs some way of knowing what the name of the channel your device will create is, but Meteor doesn’t care) or subscribe multiple devices to a single channel (either dynamic or pre-arranged) to implement a broadcast system.
October 8th, 2011 - 21:47
Hi Dave, I’ve spent a couple days tinkering with Deacon/Meteor. You demo apps worked great with your test server (2sec, 10sec channels etc) however not with my meteor server. After debugging deacon using it’s source I discovered it was the message template coming from my meteor server didn’t jive with the regex processing that deacon is doing to incoming messages. Just curious why this isn’t mentioned anywhere? Currently I’m starting meteor with “-MessageTemplate “m.p..\”~channel~\”.\”{[~text~]}\”"” parameter and it’s working now. I must be missing something obvious?!
October 9th, 2011 - 13:57
Hi Dave – There is a meteord.conf file provided as part of the Deacon source. This should probably be mentioned in the github readme – right now, the requirement to use this meteord.conf file isn’t really documented anywhere – I will log an issue to add this to the API reference, Wiki and github Readme, and hopefully do so very soon.
October 13th, 2011 - 01:01
Your official meteord.conf.. wonderful! I’m pretty sure this is the wrong place to mention this however I got deacon to hang by first connecting to meteor then rebooting my router. The socket read() infinite timeout was in effect. I changed the source to time out on the read after ~5% longer than the ping duration using setSoTimeout(). This should probably be a startup parameter after port. Now, along with some other changes, it’s able to recover from this flaky router scenario.
October 13th, 2011 - 07:29
Hi Dave-
I think you’ve independently solved Deacon’s Issue #8 – https://github.com/davidrea/Deacon/issues/8 – there is a development branch called feature_pingtest that also aims to handle the “silent broken pipe” issue. I had never thought to reboot a router for testing; flushing the routing tables without a reset at the phy layer is an effective way to break the pipe without either end necessarily knowing about it.
Please take a look at https://github.com/davidrea/Deacon/compare/master…feature-pingcheck and see how this compares with your setSoTimeout() approach; I think it does essentially the same thing. I’m interested in any feedback you may have!
October 24th, 2011 - 08:47
Hi Dave,
I’ve worked with your project, I had some feature like https support and authentication (ex : when the meteor is behind a proxy). Please let me know how we can discuss and how i can send you my stuff.
Cyrille
January 14th, 2012 - 05:33
It seems that the mailing list link is broken. Any place where I can consult the archives?
January 14th, 2012 - 10:39
Unfortunately, no – the mailing list was lost due to a multi-disk failure of the RAID at our hosting provider. Please see http://deacon.daverea.com/2011/10/deacon-mailing-list-nuked/
January 16th, 2012 - 17:15
Ohhhh I was interested in the same questions than the first poster (Chirper) and I was trying to get the answers from the mailing list. Any chance you can answer them again here:
1. Does Deacon run as a service on Android? i.e. will it receive notifications even if the app is not running? if not, can it be run as a service?
2. How many unique channels can you have? i.e. is the use case such that every phone can have its own channel?
January 16th, 2012 - 20:43
Sorry about that! To answer your questions: (1) Deacon runs its own thread, so you can use it inside a service or an activity. To make sure it runs in the background, you should run it inside a service. (2) Meteor doesn’t impose any restriction on how many channels can be hosted on a single server, since it is written in Perl and Perl is loosely-typed. The limit is actually the number of open file descriptors the OS will allow; on Linux you can check this with `cat /proc/sys/fs/file-max`. On my quad-core AMD desktop with 4GB of RAM, this limit is about 320,000. There are plenty of web sites out there that describe how the file descriptor limit on a server can be tuned…