Codes from the Underground

Objective-C Designing With Blocks

I recently started doing some Objective-C development at work. Coming from a Ruby/Python/JavaScript background, I was stoked to see that Objective-C had support for blocks.

Here’s a great tutorial on the subject.

Closures are a wonderful way to handle the complexities surrounding asynchrounous I/O. Ask any Node.js nerd, they’ll attest to this fact.

I’ve been leaning on blocks heavily while building libraries for handling I/O in Objective-C. The approach I use is as follows:

• I create a delegate class that interacts with the foundation frameworks.
• The methods of the API exposed by the delegate accept blocks, and invoke the blocks when a series of asynchrounous actions has reached a terminal point.
• The class interacting with the library does not need to worry about the intermediate actions being taken by the delegate, it just trusts that its block will be invoked with the appropriate response.

As an example of this methodology in action, here’s an asynchrounous IMAP client I’ve been working on:

https://github.com/bcoe/IMAPClient

The IMAP class itself is an NSStreamDelegate. When a user invokes an IMAP command, a block is provided. The delegate methods handle the specifics surrounding the asynchrounous I/O. Once an operation eventually completes, the block is invoked. Here’s the code that handles running a command:

An individual consuming the library need not worry about these specifics. They simply provide the block and trust that it will eventually be invoked with the appropriate response. Ultimately, a series of IMAP commands takes on a form resembling this:

cool, eh?

In the same vein, here’s what an API call looks like to an OAuth HTTP framework I’ve been working on:

I find this is a great way to decompose asynchrounous problems. It’s been working great for us at Attachments.me, as we build out our iOS stack.

— Ben (@benjamincoe)

SMTP Server Cage Match

Last week I released smtproutes: A simple, Sinatra inspired, SMTP routing server.

Read What if SMTP and Sinatra Had a Baby?

Out of curiosity, I wanted to benchmark smtproutes vs. some other libraries that one might use for building SMTP-backed-web-services.

In this post I compare the performance of:

• smtproutes (https://github.com/bcoe/smtproutes)
• Lamson (http://lamsonproject.org/)
• Pymilter (http://bmsi.com/python/milter.html)

“Three approaches to SMTP scripting enter, one approach to scripting SMTP leaves!”

The Test

I was interested in seeing the number of messages that each server could process per second, under various loads.

• I created a mailing script which repeatedly mailed an 8kb message for the first benchmark and an 88kb message for the second, testing how each server dealt with small and relatively large email messages respectively.
• I created a mail processing script for each of the servers. This received the messages and kept a running total of the number processed per second.
• I tested each mail server with 1, 4, 8, and 16 concurrent mailing scripts, to simulate various loads on the server.
• All the benchmarks were run in an Ubuntu Maverick VMware Image, on my Intel Core 2 Duo 2.26Ghz Macbook Pro.

The Results

Conclusions

Pymilter is painfully slow. Why? there’s a lot of OS level overhead that comes with receiving email via sendmail. I’m sure a Unix guru could configure sendmail in such a way that Pymilter performs much more admirably (I’m not that Guru).

Lamson is fast, it outperforms smtproutes when there are a small number of concurrent connections (a single SMTP connection sending a lot of messages to the server).

smtproutes, which uses an underlying process pool, excels when there are many concurrent connections to the server. With 16 concurrent mail scripts running, it more than doubles Lamson’s throughput.

So What?

The performance of Lamson and smtproutes helps validate the argument I’ve been putting forward in my last few blog posts (Writing a Secure SMTP Server in Python, What if SMTP and Sinatra Had a Baby?):

Running a lightweight SMTP server, independent of all the standard underpinnings of a captital ‘E’ email server, makes a ton of sense for a wide variety of applications that can be built using Email as a Service (EaaS, yep I’m going to keep using this horrible acronym).

— Ben (@benjamincoe)

What if SMTP and Sinatra Had a Baby?

Recently I’ve published several posts on the topic of composing software services on top of email. Why this recent obsession?

• People understand the paradigm of email. For some, my grandfather being a prime example, email is their main motivation for having a computer.
• Email is everywhere. It’s cross-platform, cross-device, cross-demographic. It’s estimated that there are nearly two billion email users.
•  We’ve only scratched the surface of the types of applications that can be built, using Email as a Service (EaaS, yep worst acronym ever).

It’s this last point that gets me the most excited — and I’m literally so excited I’m yelling as I type right now.

The Problem

Imagine if every time I wanted to rough out a website I had to spin up a whole J2EE stack, gross. In a similar vein, to compose a service on top of email, why should I have to run painful middleware? Quoting the ubuntu community website:

“Setting up an email server is a difficult process involving a number of different programs” yikes!

If only there were a better way!

The Solution (smtproutes)

smtproutes is what you’d get if Sinatra and SMTP had a baby. It’s not an email server with a capital S. smtproutes is a lightweight framework for rapidly prototyping web-services on top of SMTP.

Suppose I wanted to create an email service which lets you subscribe and unsubscribe to a mailing list. Here’s how we’d build this service using the smtproutes framework:

easy_install smtproutes

If the route regular expression is matched by the To: field of an inbound email message, the corresponding method will be executed.

In this example:

• mailing subscribe-username@example.com will add the user, identified by username in the regular expression, to the subscribers collection.
• mailing unsubscribe@example.com will remove the user.

It’s my hope that smtproutes can be a valuable tool for helping developers rapidly compose applications on top of SMTP. You can checkout some of its more advanced features, and contribute here:

https://github.com/bcoe/smtproutes

— Ben (@benjamincoe)