Page 1

1

Imperative and Functional Implementations

of the IMAP Protocol

ACM SIGPLAN Erlang Workshop

Victoria (BC), Canada

September 27

th

, 2008

Francesco Cesarini,

Francesco Cesarini,

Viviana

Viviana Pappalardo

Pappalardo

Erlang Training & Consulting

Corrado

Corrado Santoro

Santoro

University of Catania

Erlang Training and Consulting Ltd

A Comparative Evaluation of

© 2008 – Erlang Training and Consulting

Agenda

Purpose

IMAP Protocol Overview

Evaluation Criteria

Evaluated Solutions

Result and Conclusions

2

© 2008 – Erlang Training and Consulting

Purpose

Comparative analysis of several IMAP implementations evaluating

Performance

Capability to meet user requirements

Effort needed to develop the library

We use the metrics

Source Lines Of Code

Functionality of primitives

Memory Usage

Execution Time

© 2008 – Erlang Training and Consulting

IMAP Protocol Overview (1/2)

Client-Server protocol communication

Standardized by means of the RFC3501

POP3 heir

Data storing and email processing on the remote server

Email are not loaded locally by the client

Request-Reply model

The client starts each activity sending a request

The server generates a reply carrying data required by client's query

IMAP4 Session

FSM client sends commands in some specific order

When request are successful, client enters in a new state

3

© 2008 – Erlang Training and Consulting

IMAP Protocol Overview (2/2)

/* LOGIN INTERACTION */

C: A001 LOGIN username password

S: A001 OK LOGIN Ok

/* SELECT INTERACTION */

C: A002 SELECT INBOX

S: * FLAGS (Junk NonJunk ...

S: * OK [PERMANENTFLAGS (Junk NonJunk ...

S: * 4270 EXISTS

S: * 0 RECENT

S: * OK [UIDVALIDITY 1186814135] Ok

S: * OK [MYRIGHTS "acdilrsw"] ACL

S: A002 OK [READ-WRITE] Ok

/* FETCH INTERACTION */

C: 4 fetch 4 body[header.fields (date subject)]

S: * 4 FETCH (BODY[HEADER.FIELDS (date subject)] {54}

Subject: es

Date: Sat, 16 Dec 2006 18:19:45 +0100)

S: 4 OK FETCH complete

© 2008 – Erlang Training and Consulting

Architecture of an IMAP Client Library

•Basic IMAP client library architecture:

•Communication Layer, handles socket

connectivity.

•Low-level IMAP protocol handler, managing

request-reply communication (tags handling and

untagged/tagged response identification)

•IMAP interpreter, parsing role (transforms

server's reply into programming language native

types)

•IMAP FSM, handles IMAP's FSM (manages state

transitions)

•IMAP high-level interface, implements the

various IMAP commands by means of IMAP low-

level interface's services and IMAP parsing.

4

© 2008 – Erlang Training and Consulting

Evaluation Criteria (1/2)

Number of source lines of code (SLOC)

No blank lines and comments

Count the numbers of lines of all library's source files

“The more the SLOC the more the time required to write the software and

to test it.”

Functionality of primitives

Qualitative parameters...

...to make sense of the capability of the library to provide a complete and

transparent implementation of the IMAP commands

Related to the number and type of function/method calls

© 2008 – Erlang Training and Consulting

Evaluation Criteria (2/2)

Memory

Performance parameter

Expresses the memory usage in a language specific IMAP library at run-time

Test program:

Test program: logging and fetching a bunch of messages

Execution-Time

Performance parameter

Test program:

Test program: executing different commands and measuring time required

by each library to perform its activities.

5

© 2008 – Erlang Training and Consulting

Evaluated Solutions (1/5)

Erlang Library

Supervisor architecture, gen_server behaviour

Stand-alone application managing the most important IMAP commands

TCP/SSL connection support

IMAP Protocol handling and Parsing activity carrying out Erlang native

types

Three modules:

im_client (front-end interface)

scanning (lexical analysis)

parsing (parses server's response)

im_client module's outcome: {ResultValue ('ok', 'not' or 'bad'),

ParsedReply}, ParsedReply is the server's reply data

Check socket connection and re-instantiate it if needed, preventing

brutal closing

© 2008 – Erlang Training and Consulting

Java Library

JavaMail package, provided officially by SUN Microsystems

Platform-independent and multiprotocol (it supports IMAP and POP3 either)

framework to implement email and messaging applications

New objects

Session, to retrieve the proper Store object, Store object performs socket connection

mechanism, Folder object models email messages folder (r-w and r-o access mode), Message

object models an email message.

Two policies

“getXXX" method of Message object, to retrieve specific message's data (e.g. text,flags...),

“getMessages” (cache all messages locally) and allows client to keep data readily available,

therefore it is closer to POP3 than IMAP.

Evaluated Solutions (2/5)

6

© 2008 – Erlang Training and Consulting

C# Library

– Uses native library of .Net platform

– Three main source files:

ImapBase.cs (handles low-level client-server connection),

Imap.cs ( protocol's engine, handles IMAP commands),

ImapException.cs (manages protocol's fault and internal error)

– Custom policy to fetch email message, three methods:

FetchPartHeader fetches only the Header section of the original email message,

FetchPartBody fetches only the Body section of the original email message,

FetchMessage performs a complete parsing and retrieve the whole message, generates an XML

file such as output of its parsing activity. Client program must re-interpreter XML file to get

meaningful data.

Evaluated Solutions (3/5)

© 2008 – Erlang Training and Consulting

Python Library

– Transparency in function declaration: 1:1 mapping of IMAP commands to

methods.

– Authentication mechanism supported (IMAP AUTHENTICATE command)

– Client program must create the IMAP command (library manages Tag

numbering only)

– No Parsing...client program must parse server's reply

– All methods returns a tuple: { Tagged response, Untagged Response }

Evaluated Solutions (4/5)

7

© 2008 – Erlang Training and Consulting

Ruby Library

– Transparency in function declaration: 1:1 mapping of IMAP commands to methods.

– Authentication mechanism supported (IMAP AUTHENTICATE command)

– Client program must create the IMAP command (library manages Tag numbering only)

– Partial Parsing activity, only

FETCH

/BODYSTRUCTURE/BODY[TEXT]/BODY[section]/ENVELOPE replies are parsed

– Al methods returns a native Ruby types containing query's sequence_number and a tuple

{key,value}, the former is FETCH command keyword(FLAGS...TEXT) whereas the latter

is associated data.

Evaluated Solutions (5/5)

© 2008 – Erlang Training and Consulting

Results – SLOC (1/4)

n/a

Java

1,089

C#

1,612

Ruby

472

Python

1,189

Erlang

Lines

Languages

Erlang and Ruby perform a full parsing of server's replies:

– Erlang Parser counts 818 lines of code

– Ruby Parser counts 1048 lines of code

8

© 2008 – Erlang Training and Consulting

Results – Functionality of primitives (2/4)

Supported in

current context

Full parsing

n/a

Full parsing

No parsing

Full parsing

LIST

Full parsing

Partial parsing

Partial parsing

No parsing

Full parsing

Encapsulated

Queries

Single Messages

Only some

queries

supported

Single messages

Parameters as

string

Range or single

messages

Parameters as

string

Ranges as string

Parametric

Query

Flexible

expression of

range

FETCH

Internal w/full

parsing

No parsing

Partial parsing

No parsing

Full parsing

SELECT

Yes

Yes

Yes

Yes

Yes

LOGIN

Java

C#

Ruby

Python

Erlang

Command/

Primitive

© 2008 – Erlang Training and Consulting

Results – Amount of memory (3/4)

190,060

14,428

212,852

Java

2,748

11,148

18,800

C#

10,386

4,332

14,942

Ruby

1,684

4,400

6,748

Python

4,656

2,868

8,056

Erlang

Data/Stack

Code

Total

Language

9

© 2008 – Erlang Training and Consulting

Results – Execution Time (4/4)

6.3

n/a

52.1

0.9*

0.7

LIST

1.9

n/a

n/a

n/a

n/a

FETCH

(ENVELOPE SIZE

BODY.PEEK[HEAD

ER.FIELDS] ...)

1.2*

n/a

80.2

0.2*

1.8

FETCH

BODYSTRUCTURE

1.3*

n/a

43.0

0.2*

2.3

FETCH

BODY[HEADER.FI

ELDS]

2.9

5.3

44.5

0.2*

2.5

FETCH

BODY[HEADER]

40.2

40.0

80.2

41.1*

43.0

FETCH

BODY[TEXT]

4.5

13.2

44.3

2.1*

2.5

SELECT

30.7

32.7

26.1

45.7*

28.6

LOGIN

Java

C#

Ruby

Python

Erlang

Command/

Primitive

* = command executed without any parsing of the response

© 2008 – Erlang Training and Consulting

Results Summary

Full Parsing (Erlang Library vs Ruby Library)

– Erlang implementation outdoes Ruby library features, indeed its performances

(such as Memory consumption, Execution-time) are better than values estimated

for Ruby.

– Erlang library counts less lines of code of Ruby implementation, as demonstrated

through SLOC analysis.

Partial Parsing (Java Library vs C# Library)

– Java implementation consumes huge amount of memory.

– Execution-time are comparable even if Java has better performances in the FETCH

command handling, probably it depends on internal proprietary implementation.

NO Parsing (Python Library)

– Python has best performances (memory consumption and execution-time) but they

depend on the lack of parsing activity and Python JVM characteristics.

10

© 2008 – Erlang Training and Consulting

Conclusions

The aim is...

– ...to evaluate Erlang ability to meet requirements of productivity and

performance for a distributed system

We conclude that the Erlang library...

– ...can deliver the requirements of functionality and performance for a

distributed system

– has high execution-time without high memory cost