Using Distributed Mutual Exclusion for Coordinating VirtualMeeting in an Ubiquitous Chat System

Berto de Tacio Preira GomesOmar Andres Carmona Cortes

Rafael Fernandes LopesCentro Federal de Educacao Tecnologica do Maranhao

Departamento Academico de InformaticaAv. Getulio Vargas, 04 - Monte Castelo - 65000-000

Sao Luis - Maranhao - Brasilbertodetacio@gmail.com{omar, rafaelf}@cefet-ma.br

Abstract

The purpose of this paper is to present the applica-tion of distribute mutual exclusion for controlling thetext message exchange in a ubiquitous chat named M-SynchroTalk. This chat allows tutors and students to bein contact even on the move. The main issue is to or-ganize the entire communication when several studentsspeak at the same time and about many subjects. Allin all, the chat hold the dialog context controlling themessage broadcast by means of the distributed mutualexclusion algorithms. In this context, just one studentcould send a message at a time. To achieve mutual ex-clusion in the ubiquitous chat, the centralized and thetoken ring algorithms have been developed. The cen-tralized was implemented in two versions: human coor-dinator and computer coordinator. Preliminary resultsshow that this solution provides a well-controlled envi-ronment suitable for M-Learning environments.

1. Introduction

Chats can be use in distance education in severalways. Normally, it is only required a personal com-puters connected to the Internet. Students and tutorshave a flexible way to exchange information, becausethe participants do not have to be necessarily presentin the same physical space. This scenario belongs toan environment known as e-learning.

Nowadays, the e-learning can be combined with mo-bile computing creating the m-learning or mobile lear-ning, improving the cooperation between students and

tutors. This feature can be considered as a part of ubi-quitous computing, i.e., an environment where usersare surrounded by computational power and applica-tions everywhere [13]. In other words, an ubiquitouschat allows virtual meetings in almost any places, inany time and on the move.

However, famous ubiquitous chats such as M-Skypeand M-MSN have no coordination methods. Thus,both have their limitations in m-learning environments,because many people can speak at the same time aboutmany subjects. This situation could make the learningprocess confusing. In this context, we realize that coor-dination methods using portable devices is an essentialtask in a m-learning environment in order to hold thedialog context.

Moreover, portable devices, except notebooks, couldpresent two additional problems: connectivity loss andnarrowed screen size. The first one demands a serviceto delivery messages that were sent while the user wasnot connected (off-line). The second one could fulfilthe screen size quickly, forcing a scroll faster than onestudent could follow.

In this context, the purpose of this work is to presentcontributions for the issues pointed out in ubiquitouschats. The main contribution is the chat named M-SyncrhoTalk, which solves the coordination problemsapplying distributed mutual exclusion for exchangingtext messages. The secondary contribution is holdingan organized virtual meeting on the move.

This paper is divided as following: Section 2 showsthe related works; Section 3 describes the ubiqui-tous chat named M-SynchroTalk and its architec-ture; Section 4 addresses the implemented coordina-

2009 International Conference on Mobile, Hybrid, and On-line Learning

978-0-7695-3528-9/09 $25.00 © 2009 IEEE

DOI 10.1109/eLmL.2009.18

84

tion methods; Section 5 shows the simulation resultsand discussions about it; finally, Section 6 presents theconclusion and future works.

2. Related Works

People can speak about many subjects at the sametime in traditional chats. Oeiras [8] and Pimentel [10]propose a thread-based coordination method to dealwith this problem. Users should click in a specific mes-sage to respond it in Pimentel’s chat. Users reportednot to get used to this routine. The use of coordina-tion in chats have been discussed in other works suchas: Vahl’s [12], Oeiras’ [9] and Gomes’ [1, 2].

Vahl [12] developed a queue-based chat, where twokinds of requests to send messages could be used: res-pond to and speak to. The messages sent by respondto have more priority, i.e., requests are placed at thebeginning of the queue. Whereas the other ones areplaced at the end of the queue. Users reported thatthis approach causes some frustration in Vahl’s chat,because some requests go toward the end of the queueinstead of going forward.

Oeiras [9] improved the Vahl’s work by adding atime-based messaging control. Each user has some timeto send a message. The problem is that the time isdefined into the application code. Therefore, it can notbe adjusted during a virtual meeting if it is necessary.

An environment for ubiquitous/pervasive learningnamed MoCoTo is presented in Lopes’ [4] work. Thisinfrastructure provides a chat for mobile devices, butwithout any method of coordination. Mueller [6] showshow to implement chats using P2P technologies in cellphones. The application of chats in m-learning en-vironments are discussed in Ketamo’s [3] and No-esebakel’s [7] work. Also, the concept of pervasivecomputing for distance education was discussed inMauve’s work [5], where the author presents some ap-plications using hand-helds connected by a wirelessnetwork. None of this mentioned works apply coor-dination methods in m-learning environments.

Coordination methods based on distributed mutualexclusion were first presented in Gomes’ work [1, 2],reporting good results, in a desktop chat named Syn-chroTalk.

3. The Ubiquitous Chat System

The M-Synchrotalk is a Java application developedusing P2P architecture. Nonetheless, it uses a client-server architecture providing services such as: authen-tication, authorization, message broadcast and coordi-nation methods.

authentication.Clients and the server can be connected using GPRS

or G3 in cell phones or using a wireless network inPDAs and Notebooks. The communication betweenclients and server is done by means of TCP-IP sockets.

Clients cannot speak whenever they want while con-nected, in the ubiquitous chat. They have to send arequest asking for permission to send a message. TheServer respond back sending another message grantingor denying the access to critical region (send messa-ges). When a client receives a grant message theysend the text message to server which broadcasts itto all connected cell phones. Figure 1 presents de M-SynchroTalk Architecture. How the server deals witheach request depends on the coordination method. De-tails about each method will be presented in Section 4.

Figure 1. M-SyncrhoTalk Architecture

Tutors are able to create chat rooms. Each room iscontrolled by a thread. Also, a thread is created whe-never the server receives a client connection. Thus, theserver deals with all requests in parallel, increasing thesystem performance. Each request has a header descri-bing which service is being required and their respectiveparameters.

Messages are broadcasted by the server which main-tain a register of all connected mobile devices. The re-gistration is done after the authentication and autho-rization process. Clients must be registered to receivetext messages. If a connection is lost, the server willstore all messages for future delivery in a database. Allusers information, such as name, nickname, login, pas-sword, user profiles (student or tutor) and responsibletutors are stored in an database, as well.

Each client uses two threads on the server. The firstone sends information from client to server. The second

85

Figure 2. Class diagram - Server

one receives data from the server. Figure 2 shows aclass diagram with implementation details.

The class Server has no attributes, i.e., containsonly operations/methods. A room is created by theaddRoom method. Clients are controlled using a vec-tor of clients named group. The queue vector storesall requests for sending messages. The timer attributecontrols the time limit to send messages. The TCon-nection class controls all connections between clientsand server. The TCoordination and TTokenRing clas-ses are instanced according to the coordinationMethodattribute. This last attribute can be assigned with thefollowing constants:

• FREE MODE - Chat without coordinationmethods.

• HUMAN COORDINATION MODE - Chat usingthe centralized method with human coordinator.The class TCoordination is not instanced in thiscase.

• COMPUTER COORDINATION MODE - Chatusing the centralized method with computer co-ordinator.

• TOKEN RING MODE - Chat using the tokenring method.

Rooms are independent instances of a Room class.Therefore, each room can use its own coordinationmethods.

The client implementation is simpler than the server,as we can see in Figure 3. Now, a client is knownas user. Basically, the TConnection class controls allcommunication with the server. The TReconnectionclass is used just for controlling the connection loss.All messages are sent and received using dos and disattributes, respectively.

4. Coordination Methods

The coordination methods of M-SynchroTalk are ba-sed on distributed mutual exclusion [11]. In this con-text, sending a message is considered as a critical re-gion, i.e., just one client can send a message at a time.The distributed mutual exclusion can be implementedusing three basic algorithms: centralized, distributedand token ring. The distributed algorithm was notimplemented, because it exchange a lot of messages,increasing the network traffic and decreasing the Syn-chrotalk performance, as seen in Gomes’ [2] work.

86

Figure 3. Class diagram - Client

4.1. Centralized Algorithm

There is a central coordinator in this algorithm. Allrequest must be sent to the coordinator. If no other cli-ent is currently in critical region, the coordinator sendsback a reply granting his permission. Otherwise, therequest is put into a queue. When a client exits thecritical region, he sends a message to the coordinatorreleasing its exclusive access. Then, the coordinatortakes the first request off the queue and send the grantmessage to the client. Figure 4 presents the architec-ture of the centralized algorithm.

Figure 4. Centralized Algorithms Architecture

There are two kinds of coordinator in this approach:

tutor coordinator and computer coordinator. Tutor co-ordinator is a human coordinator. A tutor can attendthe request in the queue order (First In First Out) orchoosing what student will receive the grant message.On the other hand, the computer coordinator attendsthe requests only in the queue order. When a studentdoes not want to speak anymore, he must send back amessage informing the exit of the critical region.

Regardless which coordinator is being used, a tutorcan define the maximum time that a client could be ina critical region (sending text messages). Further, thecoordinators can retake the control of sending messagesif a student does not exit the critical region. In thiscontext, the conversation lock is prevented. Besides,tutors are able to change the coordination method atany time, as well.

The centralized approach has a shortcoming. Thehuman coordinator is a single point of failure. Thus,the human coordinator is replaced by the computercoordinator if the connection crashes.

4.2. Token Ring Algorithm

A logical ring is created in this approach. A posi-tion in the ring is assigned for each client according tothe mobile device registration order. When the ring isinitialized, the first registered client is given a token.The token circles around the ring. A client can enterin the critical region if he acquires the token. After hehas exited, he passes the token along the ring.

Controlling the message broadcast is easier in thisalgorithm, since only one client can possess the token

87

at a time. The tutor can also define the maximum timethat a client could hold the token, in this algorithm.

5. Results and discussion

The M-SynchroTalk has been developed using bothplatforms Java-SE and Java-ME. The Server was im-plemented using Java-SE and clients were implementedusing Java-ME. All clients use the CLDC 1.0 configu-ration and MIDP 2.0 profile.

As we have already mentioned, the connectionbetween clients and server is made by using TCP/IPsockets. In order to persist off-line messages were usedthe Firebird database and the Hibernate framework.Also, in order to implement the distributed mutual ex-clusion was used the ProActive framework.

The tests were conducted by means of a virtual me-eting simulation with voluntary students and teachers.All cell phones were simulated by proper Netbeans to-ols. Figure 5 shows an exemple of sending and receivingtext messages.

Figure 5. Sending and receiving a text mes-sage

Users claim that M-SyncrhoTalk is easy to use andtheir functionalities are easy to find out, during thetests . Moreover, users have neither difficulties to com-plete the authentication process nor to exchange textmessages.

Naturally, users claim that using a desktop chat iseasier than using the mobile chat. However, all usersagree that the mobility is very important nowadays.

Comparing M-Synchrotalk with ChatEd [9] it isclear that the coordination methods of M-SynchroTalkare more effective due to the following reasons:

• It is clear to find out who the tutor in the virtualmeeting is.

• M-SynchroTalk does not change the student po-sition in the queue, as it occurs in ChatEd, un-

less the tutor does that. In other words, the M-SynchroTalk coordination methods are more fairwith the student’s request.

• The period of time that a student can hold thecritical region can be set at any time in M-SynchroTalk, giving flexibility to the virtual me-eting. Whereas changing that in ChatEd is notpossible during its execution.

The most significant observation during the testswas the organization of the virtual meeting providedby the coordination methods, improving the teaching-learning process, in this context.

Teachers and students agree that the centralizedmethod is the most efficient one, because tutors havean essential role play in this method.

Some voluntaries claim that tutors seem not to payattention in the token ring method. However, allmethods are applied to students’ communication. Tu-tors can participate whenever they want, i.e., tutorscan preempt the token use. Also, tutors can changethe coordination method if required.

On the other hand, voluntaries agree that the cen-tralized method with computer coordinator and the to-ken ring can help to organize a virtual meeting if eitherthe tutor connection fails or if he is not present.

6. Conclusions

This paper presented a mobile-based chat systemcalled M-SynchroTalk. This tool can be used whentutors and students are on movement, i.e., when neithera personal computer nor notebook are available.

Developing a ubiquitous chat is a hard work, becausemobile devices have a lot of limitations. Nonetheless,it is possible to port the application to other portabledevices such as PDAs and Hand-helds.

Indeed, applying distributed mutual exclusion forcoordinating mobile virtual meeting is a new idea. Pre-liminary results indicate that the method was well ac-cepted by users. However, an evaluation using actualmobile infrastructure (real cell phones) is required.

Furthermore, the algorithms to implement the dis-tributed mutual exclusion have been modified to in-clude human aspects, i.e., they have been modified forimproving the learning process and the social interac-tion.

The coordination methods are applied just in rooms.But, if no coordination is required a room can be usedlike a regular chat, i.e., without coordination methods.

Concerning the future works, the next step is to in-tegrate M-SynchroTalk and SynchroTalk, i.e., join the

88

mobile version and the desktop version. This appro-ach is particulary interesting because it will join twolearning environments: E-Learning and M-Learning.

Other possibility is to extend de M-SynchroTalkto be used in Digital Television, creating the T-SynchroTalk. Consequently, it will be necessaryto integrate SynchroTalk, M-SynchroTalk and T-SynchroTalk.

Fault tolerance is a weak point in M-SynchroTalk.The centralized algorithm has a single point of failure.If the human coordinator crashes, a computer coordi-nator replaces him. Nevertheless, if the computer co-ordinator crashes, the entire system goes down. Otherforms of fault tolerance have to be taken into accountin the token ring algorithm, as well. Therefore, a studyabout fault tolerance is mandatory.

Acknowledgment

This work was supported in part by CNPq (Conse-lho Nacional de Desenvolvimento Cientıfico e Tecnolo-gico). Especial thanks to the teacher Claudia Paixao ofDepartamento Academico de Letras at Centro Federalde Educacao Tecnologica do Maranhao.

References

[1] Gomes, B. de T. P and Cortes, O. A. C. Sincroni-zacao em uma aplicacao distribuıda para educacao adistancia usando recursos do middleware proactive. InVII Workshop em Sistemas Computacionais de AltoDesempenho, 2006.

[2] Gomes, B. de T. P and Cortes, O. A. C. Synchrotalk:Uma ferramenta sıncrona para ensino a distancia. IN-FOCOMP: Journal of Computer Science, 6(3):82–88,September 2007.

[3] Ketamo, H. Mobile learning and training in work-place. In IEEE International Workshop on Wirelessand Mobile Technologies in Education, 2002.

[4] Lopes, R.F. and Cortes, O.A.C. An Ubiquitous Tes-ting System for m-Learning Environments. In SecondInternational Conference on Systems and NetworksCommunications, pages 118–123, 2007.

[5] Mauve, M. Enhancing synchronous distance educa-tion with pervasive devices. In In GI Jahrestagung (2,pages 1117–1122, 2001.

[6] Mueller, U. AND Young, M. and Gefflaut, A. Run-ning the windows p2p infrastructure on mobile phones.In Seventh IEEE International Conference on Peer-to-Peer Computing, pages 245–246, 2007.

[7] Noesebakel, H. The role of mobile devices in e-learning: A survey of current projects and firts ex-periences with a wireless e-learning environment. InIEEE International Workshop on Wireless and MobileTechnologies in Education, 2002.

[8] Oeiras, J. Y. Y. AND Rocha, H. V. Uma modalidadede comunicacao mediada por computador e suas variasinterfaces. In Workshop Sobre Fatores Humanos emSistemas Computacionais, pages 151–160, UFRGS -Porto Alegre - RS, 2000.

[9] Oeiras, J. Y. Y. AND Rocha, H. V. Uma ferramenta debate-papo com mecanismos de coordenacao para apoioa discussoes on-line. In XV Simposio Brasileiro deInformatica na Educacao, Manaus-AM-Brasil, 2004.

[10] Pimentel, M. G. and Sampaio, F. F. Hiperdialogouma ferramenta de bate-papo para diminuir a perda deco-texto. In SIMPOSIO BRASILEIRO DE INFOR-MATICA NA EDUCACAO, pages 21–23, Vitoria-ES,2002.

[11] Tenenbaum, A. S. Distributed Operating Systems.Prentice Hall, New Jersey, 1995.

[12] Vahl Jr, J, C. Uso de agentes de interface para adequa-cao de bate-papos ao contexto de educacao a distancia.Master thesis, Unicamp, Campinas-Brasil, 2003.

[13] Zanev, Vladimir and Clark, Rodney. Wireless coursemanagement system. In ACM-SE 43: Proceedings ofthe 43rd annual Southeast regional conference, pages118–123, New York, NY, USA, 2005. ACM Press.

89