The server address is: test.deaconproject.org (83.140.103.26)

The available channels are:

• 2sec
• 10sec
• 1min
• 10min

New in this release:

• Deacon is refactored to use a generic PushReceiver class to handle all top-level controls and configurations (i.e. start, stop, timeouts, etc.). This is sub-classed by server- or transport-specific client implementations for particular push mechanisms.
• All Meteor-specific client code has been pulled out into MeteorPushReceiver.
• The Android-specific "Deacon" class has become "AndroidPushSupervisor", which is instantiated by a hosting Android application in parallel with its chosen PushReceiver. The application registers the PushReceiver with the AndroidPushSupervisor, which will then call stop() and start() methods based on received BroadcastIntents containing network connectivity information.
• The methods in the DeaconObserver interface and DeaconObservable class have been updated, and some of the high-specificity methods have been deprecated. Those deprecated methods will still work (and, in the case of DeaconObserver, still be required in application code) but will be removed before the final 1.0.0 release.
• Important! Deacon no longer handles Android inter-thread communication using Handler and Message. This was a Demo-oriented hack to get around Android's requirement that UI object accesses only take place from the associated Activity's thread. This inter-thread communication is really the responsibility of the service that hosts Deacon (and instantiates whatever PushReceiver is required).

But wait! There's more! Not only is the Deacon Project's server moving, but the library itself has made a move - into the Android Market! Android developer Cyrille Colin has released - as a companion to an article he wrote for a French open-source magazine - the app ZnagPush. This application uses a modified version of Deacon - which Cyrille plans to contribute back to the project - to deliver notifications and updates from Nagios server monitoring software to Android devices. Cyrille's updates included improvements to the reliability of message delivery, as well as the use of a SSL connection to the Meteor server for enhanced security. If you want an early look at some of Cyrille's code, you can find it on his GitHub fork of Deacon's repository.

I am working on finding an alternate provider for the Deacon mailing list; for now, the blog will stay on its current host, but I would like to explore options for porting it to GitHub Pages...

Update 2011-10-12: I've pulled the Deacon mailing list down from host's mailman server. The redirect for existing links will be broken for a while - I'll post an update here if/when I set up a new mailing list. Since it saw very little use, either for Q&A or planning discussions, I'm debating whether to set up something new at all. In the absence of any sort of discussion group feature from GitHub, I'm leaning toward Google Groups. If you have a strong desire to see the Deacon mailing list resurrected (or any opinion on the matter) feel free to sound off in the comments...

Speaking of branches, there's something else I've been working on. Ever since reading through Vincent Driessen's nothing-short-of-stellar Git branching-model workflow write-up, I've been looking forward to using it on Deacon. After spending some time with biz-partner Pat sand-boxing around with Vincent's equally-awesome git-flow extensions and Justin Hileman's git-flow autocompletion, we're hooked. I'm already using git-flow with Deacon on my local development box, and when we're ready to merge in the bug fix I described earlier, I'll push the new branch structure to the github repository. This also means that the default branch on github will change to develop, and that master will only hold release snapshots that are used to build the .jar files found in the downloads section.

If you're using Git for version control or SCM, I definitely recommend you check out git-flow. Git is extremely flexible, and imposes very little structure on branching and merging - which is part of what makes it so powerful. But with no tool-imposed discipline, a repository with several contributors can quickly become a rat's nest of branch clutter and inconsistent tags. git-flow imposes a minimal amount of discipline that can really clean up a project's repository, and fits nicely and unobtrusively into just about any software development process. Now...if only we could improve people's commit messages!

In the last two weeks, two new contributors have expressed an interest in seeing Deacon live "beyond beta"...

The first new contributor is a Swedish company, Attendit, providers of telephony and IT support services based in Stockholm. Leading the charge there is Ola Samuelsen, an open source software enthusiast with experience in software development and telecommunications. Along with Ola, devs at Attendit will start off by paying some much-needed attention (see what I did there?) to the Deacon issues list, fixing some longstanding issues that I've been too busy to definitively resolve on my own.

From there? We have a number of other ideas in the works too, with the goals of improving Deacon's robustness and extensibility, as well as fostering more community involvement...

Around the same time I heard from Ola, the topic of push notifications surfaced in a discussion with my partners at our engineering consulting firm, AppliedLogix. We specialize in developing embedded systems, and there are certainly many ways that the embedded world can benefit from mobile push capabilities. We're still exploring ideas, but we see several ways our firm might be involved in the Deacon Project, as well as other complimentary push-centric developments.

These days, push capabilities have gone beyond being a power-user feature for mobile software - in many application genres, they're simply expected. Now, emerging uses for push data delivery have the mobile industry buzzing, with new ideas surfacing all the time. An environment like this has a large solution space - and there's plenty of room for options of all sorts. I'm looking forward to seeing Deacon become a serious contender among those options, and thanks to the help of my colleagues at AppliedLogix, and new friends at Attendit, we have a solid shot at making that happen.

Before the Deacon team reached our Alpha release, Google introduced C2DM with the arrival of Froyo. The team opted to press on, to offer developers an independent push alternative where they could control the entire pipeline and support older devices. At a proof of concept level, I believe the team achieved that goal. We got the attention of many app developers, peaking at nearly 2000 web page views per month. At one point, we were even offered a sponsorship; it would later fall through, but not without injecting a healthy dose of enthusiasm.

Unfortunately, we're learning that the cost of maintaining an open source project isn't zero. Domain names and hosting aren't free, coding and testing and responding to e-mails consume precious time, and motivating participation isn't easy. Thus far, our Pledgie button has gone unused, and adoption hasn't been strong enough to give the project much self-sustaining momentum. There have been many projects that flourish with the efforts of just a handful of curators (dcraw, jhead and dnsmasq come to mind), but strong uptake and personal usefulness are often requisite motivators for ongoing development. Frankly speaking, that simply hasn't happened here - and as a result, it's been difficult to attract contributions in the form of code or testing, and correspondingly difficult to achieve a self-sustaining critical mass.

I still believe that The Deacon Project could take off. It offers a value proposition - complete infrastructure control and support for all Android devices - that's beneficial for many mobile-app business models. For now, though, I will be scaling back my efforts to test and polish the Deacon library to free up time for some other projects. Of course, I'll be happy to continue answering questions via the mailing list, making minor improvements in the codebase, and watching the issue trackers. I'd also be thrilled (honored, even!) to receive code contributions in the form of pull requests and patches - and interested parties can certainly inquire about direct commit access. If you or your company really wants to see Deacon grow and mature, please contact me - with the right interest, conditions and support, there is always the potential to go further.

dave@server:~$ ps aux | grep meteord
meteor 10613 76.2 6.6 11156 8356 pts/1 R Feb23 13:11 meteord daemon
ddr4179 11732 0.0 0.6 3004 768 pts/2 R+ 00:00 0:00 grep meteord
dave@server:~$ ulimit -n
1024
dave@server:~$ sudo lsof -p 10613 | wc -l
1884

As it turns out, some limits in the meteord.conf file were preventing persistent connections from many of the Deacon instances in my previous test, and so only a limited number were able to hold a connection at any given time. I've fixed that now, and the tests seem to be running a bit more smoothly. More results as I get them...

Unfortunately, the results have been more cause for confusion than celebration. The new suite uses a pair of dedicated machines - one server, one client - on an isolated network with PTP-synchronized clocks and a socket-based side channel for control. It successfully addresses the error introduced by including push send time in the round-trip duration, but exposes many more weaknesses in my previous tests.

While I didn't seem to encounter this limit before, I'm now having great difficulty getting either the client or server machines past 1,024 connections - an upper-bound imposed by Linux's per-process file descriptor limit. This limit is configurable, but still seems to be leading me on a merry chase. I also discovered that the previous test didn't account for Deacon instances that weren't actually connected to the server - so I've added some extra accessors and state tracking to Deacon to prevent the test from advancing before all the clients are ready.

I'm still making progress - so stay tuned and hopefully I'll have some better news to share soon. In the mean time, suggestions are always welcome via the comments or mailing list...

My test, which is located in the source tree's org.deacon.test package, performs some simplistic load testing of the Meteor server using a whole bunch of DeaconService instances. It runs in pure Java, so it can be run from your PC rather than an Android device. Along with some delays to prevent race conditions, the first test - aptly named the Simultaneous Subscribers Test - successively generates tens of thousands of Deacon instances, connects them all to the same channel on a single Meteor server, and measures the worst-case push notification turnaround times by sending pushes containing the system time in milliseconds as the payload. When the pushes are received, the payload times are compared with the system's new current time to provide a latency measurement. The Simultaneous Subscribers Test runs until the push latency reaches a pre-defined maximum (default: 1 second), or a maximum number of subscribers are created (default: 1 million).

I'm working on a second test to prod Meteor for its maximum achievable channel count. As subscribers are successively added on the client side, each will join a new channel. Test push messages - again containing CurrenTimeMillis() payload data - will be sent to each channel, and latency measured until a maximum latency or channel count is reached.

As far as the architecture required to support widely-adopted mobile applications goes, these tests are very simplistic. In my case, they measure latency over a LAN (which is good, as it reduces the influence of intermediary bottlenecks on the results) but all pushes terminate at a single machine (which is bad, as they must be crammed through a single network interface and CPU). A distributed test, however, would require far more effort, infrastructure and coordination - so the tests in this little suite offer a good first-order look at Meteor's capabilities when used as a mobile push server. Another caveat to these test results is the way latency is measured: while using the System's CurrentTimeMillis() value as a payload is clever, it inherently lumps together the latency of push client delivery with that of connecting to the channel controller and delivering the push in the first place. I believe this is responsible for many of the outliers in the chart below.

So how'd it do on my runs? Squeaking along on my 1.8GHz Celeron-powered server (an aging but trusty Dell Poweredge 600SC with 512MB of RAM), I was able to connect 32,768 simultaneous Meteor subscriptions with a maximum latency of about 0.7 seconds, which is where I had configured the test to stop. The file descriptor limit on this machine (/proc/sys/fs/file-max) is 65,536 with only 800-or-so open descriptors at idle, so I imagine I had a lot more headroom remaining. Last night, I added a charting library and re-ran the test, this time setting the stop value around 25,000 (I wanted it to complete before I woke up this morning). The results: 25,000 instances saw a maximum latency under half-a-second, with a typical latency between 40 and 100ms:

Simultaneous Subscribers Test Result - Click for much more detailed version

This chart shows the worst-case latency observed at each subscriber count. As you can see, the results are distributed largely bimodally between around 40ms and 100ms values, with higher outliers. The linearity of this chart seems to indicate that extrapolation to far more client instances would be entirely feasible.

My next step is to complete the channel count test as well as revamp the stop conditions for this test so that it can be run over longer periods and accumulate a much larger quantity of clients. Further, I'll downsample the chart data and add error bars, so that is conveys more meaningful data with fewer raw datapoints. Stay tuned!

[Image credit: Wikimedia Commons]

Those Xperia devices represent 9 million reasons for developers to carefully consider how they implement push in their applications. That isn't to say "use Deacon, we're better!" (because admittedly, by several metrics, we're not!) but rather to suggest that a silver-bullet strategy for push notifications leaves a huge potential market unserved. While certain apps could provide "push-disabled" versions for pre-2.2 devices, developers then risk offering disparate user experiences that result in polarized opinions of their product. Rather than falling back to polling or disabling push altogether, if a developer plans to maintain a source tree for pre-2.2 devices anyway, why not use Deacon as a fall-back push provider? Given that the same application server that feeds Google's C2DM backend could be easily adapted to act as a Meteor event controller in the case that a client connects from a pre-2.2 handset.

[Xperia image: Wikimedia Commons / Espen Irwing Swang]

This past May, when Google unveiled version 2.2 of Android - codenamed Froyo - the Deacon team wrung out some commentary on the addition of built-in push capability. The gist? We think it's great that there are a few different ways to do push on Android, and we think Deacon will continue to be a good choice for many developers.

One point we made in our Froyo discussion was that many Android devices won't ever be able to use Google's C2DM push solution. A quick look at the latest adoption numbers from Google is evidence of that - nearly half of the millions of Android phones in use worldwide are running pre-2.2 operating systems. Deacon is a great way to push-enable apps on older devices - but what about devices that ought to have 2.2?

I'm referring, of course, to Samsung and T-Mobile's shenanigans of late. Yesterday, Androidspy broke a rumor from "a reliable source" that accused the two companies of withholding an otherwise-ready Froyo update for the wildly-popular Vibrant handset, in hopes of bolstering sales of the forthcoming Vibrant 4G+ model. Today, AndroidGuys followed up with some commentary which opines that such tactics - if true - are "downright wrong." Speaking only for myself, I couldn't agree more. Because not only does holding back the Vibrant's Froyo update negatively impact users, it also artificially constrains the user base of developers who push-enable their apps with C2DM.

There are well over 9 million Galaxy-S-based phones in users' hands worldwide. A sizable portion of these are doubtless the Vibrant flavor - and run Android's push-incapable "Eclair" variant. While Samsung has (indirectly, and in my opinion unconvincingly) denied the rumors, they've certainly given us another facet of the mobile application ecosystem to consider: should app developers hedge their technology choices?

In this case, integrating Deacon as a push platform not only enables compatibility with older devices that can't run Android 2.2, but also insulates app developers against manufacturers or carriers who won't keep their otherwise-capable handsets up to date. The distinction is between technical and political limitations - and Deacon can help with both.

I'll be the first to forgive Samsung and T-Mobile if they come clean and make the Vibrant's Froyo situation right - but we should still learn from the free lesson that this rumor offers up. Likewise, I'm a big fan of C2DM. I enjoy C2DM apps on my own handset, and every push option on Android has its optimal use cases - that's the beauty of a platform that offers choice. To that end, I'm also readying a post comparing Deacon and C2DM, and providing a rundown of the situations where each excels. Stay tuned...

With the 1.0 release of the Deacon Demo app, you can choose the channel to subscribe to on the Deacon project's test server, as well as stop and re-start the Deacon instance. Icons and text indicate whether the Deacon instance itself is running, as well as whether the device has a network connection. If you navigate away from the Deacon Demo app's UI, the corresponding service will create a notification if any push messages are received that contain a prime number payload - clicking the notification in the pull-down list will bring you back to the Deacon Demo activity.

You can download this app directly from GitHub using the QR Code below. Make sure you have the "Unknown sources" checkbox ticked in your device's Application Settings!

Please log any problems you encounter, or feature requests, at the Deacon-Demo issue tracker. For a look at the source code or more project details, check out the Deacon Demo GitHub project page.

The Deacon Device Testing List

The goal of the Device Testing List is to catalog the results of developers testing Deacon on their devices. There are a lot of Android devices on the market, in different form factors, with different software versions and manufacturer/carrier customizations. Deacon is designed to avoid dependence on any one device's capabilities or OS version - a strong ally in the fight against fragmentation. Nonetheless, the Deacon team can't possibly test the library in all the different hardware/software environments where it might be used. Such testing can reveal bugs and help improve Deacon - so I'm hopeful that those who are running Deacon-powered apps on the spectrum of Android devices will log their results on the Device Testing List.

Keep an eye on the list as we develop the format and add devices. So far, only the devices that I have personally tested appear - but I hope that the Deacon community changes that quickly!

Note: As far as I can tell, you just need a GitHub account to edit the Deacon Wiki, which hosts the Device Testing List. If anyone has trouble making edits, please let me know by comments or e-mail!

The Deacon team is proud to annouce the release of the Beta version of the Deacon push notifications library for Android!

If the Deacon Project blog's hit stats are any indication, weekends on the web are pretty quiet when it comes to Android Push Notifications. But this weekend has been a busy one around Deacon HQ... After plenty of third-party testing over the last month, as well as some code updates and experimentation, this weekend marks the entry of the Deacon push library for Android and Java to "Beta" status.

In addition to all the functionality included in Deacon's Alpha Release, Beta includes updated design information, the beginnings of an automated test suite, and several bug fixes. Contrary to previous indications on this blog, the Beta release does not include compatibility with Google's C2DM framework. While this was an exciting potential feature, the Deacon developers received precisely zero interest in it from the developer community. Unless robust demand for C2DM compatibility appears in the comments section, or on the Deacon Project mailing list, further development in this area will not be pursued.

In the run-up to this Beta release, several developers contacted me to express an interest in Deacon. Were it not for their enthusiasm, and their constructive feedback on Deacon's operation, I would likely have shelved the project entirely. Special thanks to Lee J. (@britishturbo, developer of Tweetissimo) and Kasper Holtze for their encouragement and interest.

At this point in Deacon's evolution, the library should be sufficiently robust to permit development of push-based Android and Java applications with a reasonable expectation of performance and stability. While Deacon has not (to my knowledge) been tested in large-scale deployments or production environments, the real-world tests to which it has been subjected indicate that it is robust to changing network conditions, consumes network bandwidth efficiently, and minimally impacts handset battery life. It is my hope that this Beta release will encourage more developers to actively test Deacon in their push-based Android applications, and that they will report on their experiences on Deacon's mailing list and bug tracker.

Following this Beta release, I plan to move to a largely reactive and contribution-based model for Deacon development. I will gladly follow up on reported issues, respond to mailing list inquiries and make any code changes needed. Further, I will welcome submitted patches and pull-requests in order to incorporate code changes from the community. However, barring changes resulting from my own Android app development activities, I do not plan to aggressively add features or enhancements. Deacon, like most Open-Source projects, belongs to its community, and community involvement will be the key driver in its ongoing evolution. In short: Ask and ye shall receive. Code and ye may contribute. But sit thee not silent.

[Image: Wikimedia Commons (public domain)]