Towards an easier way to build multiuser applications

1
Towards an easier way to build multi-user
applications

• UCL Donatien Grolaux - 2002

2
Interactive Multi-User Applications

• Class of IMUA of interest here
• IMUA that are still useful in single user
  situations
• IMUA where users interactions can conflict
  conflicting drawing commands in vector based
  drawing application
• IMUA where the sum of local knowledge of all the
  participant applications cover the global
  knowledge of the IMUA (no server explicitly
  required)
• Examples Drawing applications, agenda, notepad,
  pager, chat, address book,

3
Good properties sought after

• Direct connections between participants,
  requiring no centralized server
• Dynamic connections
• Fault tolerance
• Consistency of data
• Lag free, independence of network delays

4
Example application Agenda

• A simple Agenda application where users can
  connect together and share their agenda
• This is a simple application, therefore it should
  be simple to develop !

5
Difficult problem

• Several different area of expertise required
• UI, concurrency, p2p, fault tolerance and often
  DB
• Lack of tools and methodology for simple and
  straightforward development

6
Developer point of view

• Interested in the single-user functionalities of
  the application
• How can users edit data ?
• Interested in specifying the multi-user behavior
  of the application
• How do users compete for resources, how are
  conflicts solved ?
• Interested in new multi-user specific
  functionalities
• How can the application help several users in
  achieving their goal ?

7
Developer point of view

• In general only interested in what is specific
  to his application
• Not interested in the programming techniques
  involved by the communication layer
• At first, not interested in the multi-user aspect
  of the application, only interested with the
  basic functionalities of the application

8
Solution analyzed

• Warning ad-hoc solution for the Mozart platform
  only
• First step
• Let the developer implement a single user only
  version of the application

9
Second step make it multi-user

• Separation of concern principle isolation of the
  distribution and multi-user semantics from the
  rest of the code
• Event-driven pattern
• Events are the points of interest for the
  multi-user functionalities
• Events place messages in a FIFO stream

10
Agenda application

• Point of interest here the add method of the
  MyAgenda object
• meth add(Time Label)
• ...
• end
• Placing a event handler on the add method call on
  that object
• MyAgendaNew AgendaClass init
• is replaced by
• MyAgendaNewOC AgendaClass init
• MyAgenda ListenMethodCall(add)
• EventStreamMyAgenda GetEventStream()

11
Globalization

• We have a technical way of listening to what
  requires a multi-user treatment in the
  application
• Make it global by broadcasting this information
• ForAll EventStream
• proc M Broadcaster.sendAllButMe M end
• Broadcaster if a FIFO asynchronous p2p
  fault-tolerant message delivery system

12
Reception

• Other participants receive the broadcasted
  messages
• Messages can be injected into the application
• ForAll Broadcaster.receiveStream
• proc M MyAgenda Apply(M) end

13
Coherence and privacy considerations

• No enforced coherence of data
• Many ways of defining coherence of data
• Left to the developer
• Mainly in a single part of the text of the code
  of the application
• Simple cases are equivalent to message filtering
• No privacy considerations
• Also left to the developer

14
Example Agenda privacy

• Outgoing messages are filtered and transformed to
  preserve privacy
• ForAll EventStream
• proc M
• case M
• of meth(add(Time Label)) then
• Broadcaster.sendAllButMe
• meth(add(Time appointment))
• end
• end

15
Third step Add new multi-user functionalities

• Agenda example new color parameter for the add
  method and filtering upon message reception
• ForAll Broadcaster.receiveStream
• proc M
• case M
• of meth(add(Time Label)) then
• MyAgenda Apply(meth(add(Time Label
• colorred)))
• end
• end

16
Conclusions and future work

• Work still in progress !
• For simple applications, this strategy seems well
  suited.
• Many useful multi-user applications are very
  simple (pagers, chats).
• For more complex applications, this approach
  should at least allow the creation of low cost
  prototypes.
• Can fully take advantage of p2p protocols to
  connect participants.

17
Real question is

• Several applications are currently being
  developed to validate the approach and try and
  bound its limits.
• How far can we go with this approach
• How far does it make easier (less expensive) to
  write multi-user application than other methods ?
• Can it be improved ?