iFlame Design Notes

Brian D. Carlstrom and David M. LaMacchia


Over the course of the past several years, a great demand has been made for different means for people to send personal communications to others on the Internet. From a UNIX standpoint, developments have been numerous and varied: network aware versions of the write command and various talk programs allow two users to communicate as well as more complex systems such as electronic mail systems, IRC, and Athena's Zephyr which allow multiple users to send information to a wider audience.

There are several problems with these systems. A standard networked version of write is not provided by vendors. talk does not work reliably between platforms for historical reasons. Email does not work well for online conversations. IRC conversations, as well as talk's, focus one's attention solely on the communication, making it hard to get other work done. Many of the systems do not adequately address authentication and encryption. Many offer only two-way conversations when there is often a need for group discussion. While Zephyr provides a style similar to what we want, it lacks controls on private groups and has scalability problems.

We propose i-Flame as a solution for an integrated message system. It is designed to allow various interfaces depending on the user's preferences backed by authentication and encryption and a scalable model for providing Internet wide service. Below is a discussion our initial design which will be further refined as time goes on.


The heart of i-Flame resides in forums. A forum is a place were communication takes places between users. Underneath, a forum consists of three parts. The first part is a collection of Access Control Lists (ACL's) that constrain who can read a forum, who can write to a forum, and who can administer a forum. The latter parts are the lists of locations of active readers and writers of a forum. This general model allows the user a lot of room for customization. For example, a forum to receive private messages would allow anyone to write but only would allow one reader. However, a user could have a negative ACL to disallow certain users from writing to them. Login forums afford another example. A login forum would have one allowed writer, the person logging in, and multiple readers, supposedly friends wishing a message to know when their friend is logging in and out. Similar to the first example, a negative ACL could be used to prevent others from listening to a login forum for privacy reasons. Forums with multiple readers and writers would be suitable for group communication.


When a client joins a forum, its location is added to the list of locations of active readers. The location uniquely identifies a client in the i-Flame system. A user may be join forums multiple times from different locations. Each Internet location entry is composed of both an IP address and port number. It is important to note at this point that port numbers will be dynamically chosen by the client when started: multiple users on a single machine will all be able to have their own i-Flame clients.

Software Components: Clients and Servers

i-Flame's scalability stems from the relationship between clients and between client and server. Traditional client-server systems such as Zephyr tend to favor centralized servers. i-Flame moves away from this model making the clients bear more of the load. In the i-Flame system, the server is responsible for maintaining forum membership lists. The messages passed in the i-Flame system are strictly between clients. Before this can be accomplished, the client must add itself to the list of writers to the forum. At this point it will receive a list of locations from the server and cache this list locally. From this point on the server will notify the writing client of changes in forum readership.

Once a client has locally cached the locations of forum readers, the client sends its message data directly to the locations without any need to consult with the server. The effect of this is that the client's machine bears the brunt of the work in sending a message, only slowing down the users of that workstation, instead of all i-Flame users (in comparison, the three server machines that Zephyr requires take the brunt of the workload). This allow i-Flame to be more scalable because, while servers are linked to share location information, the primary use of i-Flame --- message passing --- transpires at the client level. Client performance is proportional to the number and size of forums the user wished to be involved in. Users who only are interested in personal messages are not affected by the load of larger multi-user forums.

For example, a user wants to send a message to a forum of 200 users. In a server-centered system, the server would have to send 200 duplicate copies of that message, bearing a huge weight and slowing down performance for other users. In i-Flame's model, the client of the user sending the message would send 200 duplicate copies of the message, constraining the performance loss solely to the sender.

Authentication and Encryption

The i-Flame system tries to maintain a flexible approach to authentication and encryption. These are still volatile areas of development and there are many competing systems. We wish i-Flame to interact well with systems of varying capability, will still supporting a Least Common Denominator (LCD) level of security to its users.

Authentication is of chief importance to the i-Flame forum-location server. Without proper authentication, the capabilities of the ACL controlled system are weakened. As a minimum, login-password pairs provide a LCD system. Better yet, when available, a Kerberos style trusted-third-party system is appropriate. Also, a PGP signature system would provide a more widely available mechanism for authentication.

Encryption is important in protecting client message data. If no crypto system is available, possibly due to export control problems, the system can operate without one. No commonly used systems currently provide built in encryption. We will explore the DES capabilities provided by the Kerberos libraries as well as PGP, the 'Net's de facto standard for person to person encryption.


The i-Flame system hopes to eliminate many of the problems of its predecessors as well as provide new functionality. The primary potential is because of its unique client heavy design with a server maintained cache. It will be interesting to see if performance costs of maintaining the writers' cache of readers will be low enough for the system to be truly scalable. In any case, the system will provide a unique opportunity to combine many systems software ideas in new and interesting ways.