[Cu-wireless] write a server-free chat application!

[pfolk at gargtech.com]

First of all, to answer the questions of reliable multicast raised last
night, that is 100% not what SCTP is about, howver RMTP (and RMFTP, for
other purposes, at http://www.bell-labs.com/project/rmtp/) seems like a
good candidate.  I haven't yet figured out whether it is a many-to-many
solution, or a core-based tree.  Also, it might be overkill for chat.

> The discovery process is generally centralized; by "discovery" I mean the
> process of:
>  - registering a username
>  - announcing your presence
>  - finding other usernames (directory)
>  - finding other usernames' presence
>  [ probably others ]

I would think that the main use of multicast in this would be to discover
chat "rooms".  A host wishing to open a room would send a message saying
"Hi, my public key is Q, and I am hosting a chat called R at ip S, and
this announcement is message number T," and then sign it with its private
key.  The (Q,R) pair would be globally unique, with the other values
obsoleted when a message about (Q,R) with more recent T is sent.  People
listening would then contact S, and set up a reliable (TCP) encrypted
session for participating in the chat room (which would be centralized
to the machine hosting that room, but not some monster napster-like cen-
tral server for all rooms).  The centralization is necessary, because it
is very confusing if you say "X" and I say "Y", and some people see "X Y"
but others see "Y X" =)

The reliable connection could either be one-way (My statements go to the
server, but the server uses a multicast transport protocol to send the
messages to the rest of the participants in the room), or two-way (all
the chat messages come to me through the reliable connection).  I'd think
that both options should be available to all participants, in case they
are not on multicast-enabled networks.  The initial setup of the reliable
connection should also involve negotiation of a chat-room "session" key,
which all messages would be encrypted with (as well as signed by the
chat room key Q).  This makes it so only participants can listen in on
the chat room, but only the server can originate messages.


Conversely, someone wanting to join a chat room (Q,R) would send a dis-
covery message with increasing TTL saying "Anybody know the current
digits for chat room (Q,R)?"  Eventually this would reach either a
participant in (Q,R), or the current server for (Q,R).


Assuming not-too-many participants (a hundred, max, say), I think that
the above would work well without multicast for the chat transport.  
For more participants, you would need to decide what to do based on how
much each participant adds to the conversation.  If it's a virtual env-
ironment, where you're getting roughly the same amount of traffic from
each listner, we should try implementing the thing I wrote my thesis on
at Reed (I'll try to put a copy online sometime soon), or RMTP (if that
fits the bill--the problem would be if it requires support on inter-
mediate routers other than standard multicast support).  If there are
many lurkers, it might be more feasible to just use a multicast group.

Peter