iFlame Design Notes
Brian D. Carlstrom and David M. LaMacchia
Introduction
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.
Forums
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.
Locations
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.
Conclusion
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.