Cost-effective Web-based Media Synchronization Schemes for Real-time

Distributed Groupware

Maarten Wijnants, Peter Quax and Wim Lamotte

Hasselt University – tUL – iMinds

Expertise Centre for Digital Media, Wetenschapspark 2, 3590 Diepenbeek, Belgium

Keywords:

Multimedia, Inter-Destination Media Synchronization (IDMS), Group Synchronization, Cost-beneﬁt Analy-

sis, synchronous MediaSharing (sMS).

Abstract:

A multitude of application domains beneﬁt from synchronized multimedia content presentation and playback

across spatially scattered client stations. Online remote tutoring, telework and teleconferencing, and the non-

co-located synchronous browsing through a digital photo album are merely some examples of potential use

cases, which are referred to collectively as real-time distributed groupware. This paper presents ﬁve concrete

schemes that realize media synchronization over the Web. The proposed techniques have been implemented

and experimentally validated as part of the synchronous MediaSharing (sMS) service, a framework which

grants geographically dispersed users the ability to share and synchronously consume digital pictures and

video clips. All ﬁve schemes are completely Web-compliant, achieve relatively loose synchronization accu-

racy, and can be categorized as being non-distributed in the sense that they require centralized coordination.

Besides being technically compared, the synchronization solutions are subjected to a high-level assessment in

terms of their infrastructural requirements and the thereby associated necessary operational expenditure.

1 INTRODUCTION

The shared, co-located consumption of multimedia

such as pictures and video clips occupies an important

niche in media-centered communication paradigms.

In this model, people physically convene in order to

consume particular media content in the presence of

each other. The co-located setting hereby often leads

to highly rich human interactions. As an example, it

has been found that jointly browsing through a phys-

ical photo album gives rise to the evocation and po-

tentially even the reliving of shared memories (Sar-

vas and Frohlich, 2011). Another example is given

by the fact that people typically enjoy watching the

live television broadcast of important sport events to-

gether with friends, because the social contact adds an

additional and highly valued dimension to the setting.

Unfortunately, numerous practical factors like

travelling overhead and time constraints increasingly

prevent group members from physically meeting up,

both in professional and recreational scenarios. At the

same time, due to the popularization of Online Social

Networks (OSNs), international contacts are becom-

ing common practice. To mitigate the potential disad-

vantages (concerning social interaction) induced by

a distributed setting, we have previously proposed a

digital media sharing and synchronization framework

called synchronous MediaSharing (sMS) that emu-

lates a sense of co-presence and physical togetherness

for geographically dispersed content consumers (Wi-

jnants et al., 2012a). The framework is exclusively

built around Web technologies and standards in order

to maximize its adoption and market penetration po-

tential (by avoiding platform lock-in). User-centric

research has revealed that the sMS tool nicely ﬁts in

with the contemporary content sharing and consump-

tion habits of multimedia amateurs; furthermore, the

system has been found to be largely complementary

to existing digital multimedia sharing services like

Flickr and YouTube (Wijnants et al., 2012b).

At the core of any synchronous media sharing

platform lies its real-time content synchronization

procedure. The synchronicity requirement namely

dictates that spatially distributed participants need to

be presented the same content at (approximately) the

same time. In the literature, this concept is sometimes

denoted by the term group synchronization (Boronat

et al., 2009) or Inter-Destination Media Synchroniza-

tion (IDMS) (Stokking et al., 2010). This paper will

present ﬁve synchronization schemes that have been

149

Wijnants M., Quax P. and Lamotte W..

Cost-effective Web-based Media Synchronization Schemes for Real-time Distributed Groupware.

DOI: 10.5220/0004369401490154

In Proceedings of the 9th International Conference on Web Information Systems and Technologies (WEBIST-2013), pages 149-154

ISBN: 978-989-8565-54-9

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

developed in the context of the sMS platform. Besides

describing the technical implementation of the differ-

ent methods (in Section 2), they will also be compared

in terms of their economic effectiveness by investigat-

ing their deployment and hosting demands (in Sec-

tion 3). It is hereby emphasized that the ﬁndings and

results described in this article are not bound to the

sMS framework but instead, through generalization,

are applicable to many Web-based services that are

conceptually situated in the same time, different place

category of the groupware typology introduced by Jo-

hansen (Johansen, 1988).

2 SYNC SCHEMES

This section presents a total of ﬁve schemes that

achieve content synchronization in the sMS sys-

tem. Given the system’s Web-conformance design

premise, an unconditional prerequisite for the devel-

oped group synchronization solutions was that they

had to be completely Web-compliant. Another trait

that is shared by all proposed schemes is that they

are not very strict, in the sense that they yield rel-

atively loose group synchronization; timing discrep-

ancies amounting up to a handful of seconds might

occur across participating sites. Qualitative end-user

research has proven that the level of inter-destination

synchronization that is attainable by the presented

schemes sufﬁces for entertainment purposes and for

recreational applications of the sMS platform (Wij-

nants et al., 2012b). Other application domains (e.g.,

distributed learning) might demand more strict syn-

chronization solutions (Gutwin, 2001). A next simi-

larity is that all ﬁve implementations conceptually be-

long to the master-slave receiver category in Boronat

et al.’s taxonomy of group synchronization schemes

(Boronat et al., 2009). Finally, the schemes are all

non-distributed in nature as they depend on a central

process to streamline the synchronization procedure.

2.1 Webserver plus AJAX

The rationale of this scheme is that synchronization

records are stored in, and fetched from, a centralized

location. In particular, whenever a user actively mod-

iﬁes the state of a sMS session, an AJAX transac-

tion is initiated by his client to invoke a server-side

PHP script, which in turn inserts the transported con-

tent synchronization payload in a relational database

(RDBMS). Conversely, clients periodically solicit the

most recent synchronization data that pertains to their

current sMS session from the server (again via AJAX)

and apply the response locally. Factual implementa-

tion details can be found in (Wijnants et al., 2012a).

2.2 Synchronization in the Cloud

An interesting alternative to the use of a dedicated

and privately hosted webserver for the distribution of

synchronization instructions (as described in Section

2.1), is to resort to the Platform as a Service (PaaS)

cloud computing service model. Due to hardware vir-

tualization technology and economies of scale bene-

ﬁts, a cloud-deployed solution will typically be more

resource-efﬁcient and cost-effective (see Section 3).

At the same time, the synchronization scheme auto-

matically inherits the advantageous properties that are

typically associated with cloud hosting, including dy-

namic scalability, the availability of powerful cloud-

side APIs that foster application implementation, and

highly reliable Quality of Service (QoS) guarantees.

In this particular case, the synchronization model

has been realized on Google App Engine (GAE), the

PaaS cloud computing service provided by Google.

The model’s design largely mimics that of the dedi-

cated webserver deployment from Section 2.1: clients

rely on AJAX to push sMS synchronization data to

a back-end repository, and remote clients obtain the

pushed data from this repository. Some signiﬁcant

differences in terms of implementation however ex-

ist between both approaches. First, the back-end soft-

ware has in this case been implemented as JavaServer

Pages (JSPs) instead of as PHP scripts. Secondly, the

synchronization instructions are server-side persisted

by means of a schemaless NoSQL object store that

guarantees automatic data storage scalability through

the use of a distributed architecture. Third, clients do

not need to explicitly and periodically poll the server

to be informed of the most up-to-date sMS session

state. Instead, as soon as the cloud application re-

ceives novel synchronization instructions, it will in-

stantaneously and automatically push these instruc-

tions to all clients that are participating in the involved

sMS session. This type of selective broadcast behav-

ior is enabled by the Channel API service for Java-

coded GAE applications.

The cloud solution technologically clearly out-

performs the dedicated webserver synchronization

scheme. Not only do GAE’s intrinsic scalability

features guarantee adequate performance under high

workloads and large data sets, the push-based Chan-

nel API additionally expedites the dissemination of

synchronization records among involved client termi-

nals and as such improves sMS session consistency.

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

150

Figure 1: Synchronization via a public Facebook Page.

2.3 XMPP MUC

The Extensible Messaging and Presence Protocol

(XMPP) is essentially intended to realize the distri-

bution of (instant) messages and presence informa-

tion among distributed sites. It is an open XML-

based IETF standard that has been designed with ex-

tensibility in mind. One example of an XMPP ex-

tension is the Multi-User Chat (MUC) speciﬁcation.

Via the deﬁnition of a room or channel concept, this

extension introduces textual group chat functionality

in XMPP that unlocks controlled one-to-many text-

based communication. Note MUC’s large conceptual

resemblance to the GAE Channel API discussed in

Section 2.2. Also remark that, thanks to the openness

of the protocol, anyone is allowed to develop and host

a (proprietary) XMPP server; many public servers are

available to which users can connect free of charge.

The XMPP MUC functionality has been exerted

to implement inter-destination content synchroniza-

tion according to the publish-subscribe interaction

paradigm. sMS session participants are grouped in

a unique MUC room, after which synchronization-

related messages are broadcast within this room. This

implies that, when a user modiﬁes the state of the

session, his client transmits a state description mes-

sage to his XMPP server, which in turn propagates the

message to all other session participants on the basis

of the member list of the corresponding MUC room.

2.4 Facebook

Facebook offers a number of SDKs for different pro-

gramming languages (including PHP and JavaScript)

that enable software developers to interface with

the platform and to build socially-inspired applica-

tions. The proposed Facebook-mediated synchroniza-

tion approach has been realized exclusively by means

of the Facebook JavaScript SDK.

The basic idea of this implementation is to ex-

change sMS session state information by means of a

specialized yet public Facebook Page (see Figure 1).

Whenever a new sMS session is created, the initiat-

ing client publishes a post on this Facebook Page and

records the post’s unique Facebook ID. The posted

message holds conﬁguration information about the

session, including the URL of the Media RSS feed

that syndicates the content that is being shared. On the

basis of the unique ID, other users are able to retrieve

the Facebook post and to join the associated session

by processing the data contained in the message. Syn-

chronization records on the other hand are communi-

cated as comments on the Facebook post that corre-

sponds to the involved sMS session. Session mem-

bers repeatedly query the Facebook Page to acquire

the most recent comment on the relevant post, parse

the synchronization record it represents and apply the

resulting data locally to achieve content synchroniza-

tion. To prevent an explosion of the number of syn-

chronization comments, the model instructs clients to

delete all their previously published comments that

pertain to a particular sMS session when posting new

synchronization instructions for this session. Also re-

mark that, by relying on a specialized Facebook Page

as the communication medium, the synchronization

scheme avoids pollution of the timeline of the partici-

pating users’ Facebook account with synchronization

messages that are meaningless to humans.

Although the described synchronization model is

technically valid, it suffers from two practical is-

sues. First, Facebook dynamically limits the volume

of posts and comments that applications are allowed

to publish within a certain time interval, as well as the

rate at which this can occur. As these publishing con-

straints are enforced on-the-ﬂy and in an opaque and

largely variable manner (depending on, for instance,

the current workload experienced by the Facebook

back-ofﬁce), they are impossible to predict. This in

turn unfortunately undermines the dependability and

reliability of the synchronization scheme. Secondly,

considerable time (in the order of minutes) might pass

before a post or comment is replicated to all the Face-

book servers. As a result, session participants who are

geographically vastly dispersed are likely to witness

signiﬁcantly variable delays before they gain access

to published synchronization data.

2.5 Twitter

As is the case with Facebook, a number of APIs are

available to interface third-party applications with the

Twitter platform. There for instance exist RESTful

API methods to post tweets. In addition, the so-called

Twitter Streaming API grants developers low latency

access to the global stream of tweets by allowing them

to set up a long-lived HTTP connection to the Twitter

Cost-effectiveWeb-basedMediaSynchronizationSchemesforReal-timeDistributedGroupware

151

Figure 2: Synchronization via a public tweet.

back-ofﬁce, over which tweets will then be streamed

incrementally. In combination with extensive ﬁlter-

ing mechanisms (hashtag-based, for example), appli-

cations in this way obtain near-real-time access to ex-

actly the type of tweets they are interested in.

In the Twitter-mediated synchronization model,

the content synchronization data is exchanged as pub-

lic tweets (see Figure 2). These tweets are published

on the Twitter account of the user who altered the state

of the sMS session and they include a speciﬁc hashtag

(#syncMedSha) as well as an ID that uniquely deter-

mines the relevant session. A PHP daemon running

on a back-end webserver leverages the Streaming API

to ﬁlter all the tweets that transport synchronization

records, parses them, and persists the extracted syn-

chronization instructions in a local RDBMS. Clients

iteratively query this database (by issuing an AJAX

request to a server-side PHP script) to retrieve the up-

to-date state of the sMS session in which they are cur-

rently engaged. Note that, as opposed to the Facebook

scheme described in Section 2.4, nonsensical mes-

sages (from a human perspective) are in this solution

actually being introduced in the user’s tweets list. To

minimize the potential detrimental effects of this ap-

proach, a background client-side thread exploits the

Twitter REST API to delete synchronization-related

tweets that were previously issued by the local user

and that have become obsolete.

Besides being less elegant than the Facebook im-

plementation (due to the use of public and personal

tweets to communicate synchronization instructions),

the Twitter-powered synchronization method faces a

number of constraints that are dictated by Twitter

and that render the solution to be suboptimal at best.

First, tweet length restrictions limit the potential pay-

load volume of synchronization messages. Secondly,

Twitter explicitly advises not to access the Streaming

API from within Web browsers given their Same Ori-

gin Policy with respect to the execution of JavaScript

code. As a result, a substantial ﬁnancial overhead

is incurred due to the necessity to deploy a server-

side component (see also Section 3). To aggravate

matters, unnecessary additional delay is introduced.

Third, like Facebook, Twitter imposes rate limits on

the usage of its APIs and enforces restrictions to

ensure fairness among users and to protect the ser-

vice from downtime due to overload. Contrary to

Facebook however, these usage restrictions are well-

documented. This implies that a strict per-day upper

bound is set on the number of synchronization mes-

sages that a user will be able to disseminate. Finally,

again analogous to the Facebook implementation, the

publication of synchronization data tends to be slow,

as the posting of tweets via the Twitter REST API is

typically non-instantaneous.

3 COST ANALYSIS

Section 2 has indicated that substantial differences

exist between the ﬁve solutions in terms of syn-

chronization efﬁciency and performance. Now, we

will take a high-level look at the ﬁnancial repercus-

sions that are associated with the adoption of each of

the approaches. Commercial applications might rate

cost-effective deployment and maintenance models

equally important to synchronization performance.

Table 1 summarizes the economic implications

due to infrastructural requirements for each of the de-

scribed synchronization solutions. Three out of the

ﬁve schemes can be rolled out without incurring any

back-end hardware deployment cost. Of these three

technologies, XMPP MUC and Facebook are further

characterized by the complete absence of operational

or maintenance-related expenses, which makes them

particularly attractive. The same is also true for the

third solution, Synchronization in the Cloud, given

that the distributed groupware service does not violate

the resource quota of the PaaS provider’s zero-cost

policy. Typically, these quota sufﬁce for a Proof-of-

Concept deployment, and often even for a small-scale

commercial installation of the service.

When collating the Webserver plus AJAX and the

Synchronization in the Cloud solutions, the latter will

typically outperform the former in terms of ﬁnancial

efﬁciency, even if the involved synchronous applica-

tion would exceed the resource quota associated with

the PaaS vendor’s cost-free pricing model. Many

cloud platforms leverage a pay-per-use billing sys-

tem, whereas traditional webserver hosting typically

imposes a monolithic monthly or yearly fee. This im-

plies that cloud-based solutions in most cases will ex-

hibit a much more favourable cost-beneﬁt trade-off.

Finally, although the Facebook-mediated synchro-

nization scheme scores highly in the bird’s-eye cost-

beneﬁt analysis, one must keep in mind the practical

limitations that are entailed by this approach. A de-

veloper who opts to host his application on Facebook

is completely dependent on Facebook’s hardware in-

frastructure. In this context, no guarantees are given

in terms of performance, as there is no notion of Ser-

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

152

Table 1: Hosting and deployment requirements and associated operational expenditure.

Technology Necessary infrastructure and cost estimate

Webserver + AJAX Webserver hosting (with PHP and RDBMS support) and management.

Synchronization in

the Cloud

All back-end hardware is hosted and managed by the PaaS cloud provider. Actual cost

depends on the cloud provider’s pricing model. Many vendors (including GAE) offer free

policies for applications that do not exceed predeﬁned resource usage quota (e.g., CPU).

XMPP MUC MUC-enabled XMPP server(s). Complimentary XMPP servers are abundantly available.

Facebook None. Facebook’s back-ofﬁce takes care of storage and dissemination of sync instructions.

Twitter Webserver hosting (with PHP and RDBMS support) and management.

vice Level Agreements (SLAs) between the developer

and the platform holder. As an additional disadvan-

tage, a software developer has no control whatsoever

over the behaviour of the Facebook back-end. Section

2.4 has for instance clariﬁed that Facebook’s dynamic

rate limiting policy transforms the proposed synchro-

nization scheme into a highly unreliable and unpre-

dictable service whose performance will be unaccept-

able for the majority of online synchronous applica-

tions. Note that the Twitter-powered synchronization

scheme suffers from identical issues.

4 CONCLUSIONS

This paper has presented and compared a total of ﬁve

concrete hosting and deployment strategies for Web-

based group synchronization applications that involve

the synchronous presentation and consumption of

multimedia content at geographically distributed end-

points. The comparison was not limited to the tech-

nological methodology and performance of the pro-

posed schemes, but also encompassed a non-detailed

economic cost-beneﬁt analysis. The described solu-

tions namely all rely on a central entity that man-

ages the inter-destination synchronization, and setting

up and maintaining such centralized infrastructure

might have signiﬁcant ﬁnancial implications. The

study has revealed that a XMPP MUC-powered so-

lution is not only highly efﬁcient in terms of con-

tent consistency performance (courtesy of its ability

to disseminate synchronization instructions in a push-

based, multicast-like fashion), it is in addition gratu-

itously realizable given the abundance of public and

complimentary XMPP MUC servers on the Internet.

A cloud-hosted synchronization coordinator that uti-

lizes the PaaS service model has been found to be

a decent runner-up. With regard to technical fea-

tures and synchronization efﬁciency, the XMPP MUC

and Synchronization in the Cloud schemes are largely

comparable. In terms of economic cost-beneﬁt ratio,

cloud platforms generally invoice applications only

for the back-end resources that they actually con-

sume. The pricing models of many cloud computing

providers even incorporate cost-free plans, yet the re-

source quota bestowed upon these models are likely

to be unsatisfactory when envisioning a comprehen-

sive deployment of a real-time distributed groupware

application. Finally, despite their conceptual attrac-

tiveness and theoretical feasibility, the Facebook- and

Twitter-situated content synchronization techniques

have been proven to be practically unsuitable. The

limitations enforced by both Facebook and Twitter

concerning the usage of their back-end infrastructure

are so strict and time-variant that they rule out the

building of a dependable, robust and adequately per-

forming synchronization scheme.

ACKNOWLEDGEMENTS

Part of the research described in this article was per-

formed in the context of the iMinds project 3DTV 2.0.

This project is co-funded by iMinds, a research insti-

tute founded by the Flemish Government. Companies

and organizations involved in the project include An-

drome NV and TP Vision, with ﬁnancial support of

IWT Flanders. We thank Davy Vanclee for the imple-

mentation of the Sync in Cloud and FB schemes.

REFERENCES

Boronat, F., Lloret, J., and Garc

ıa, M. (2009). Multi-

media Group and Inter-stream Synchronization Tech-

niques: A Comparative Study. Information Systems,

34(1):108–131.

Gutwin, C. (2001). The Effects of Network Delays on

Group Work in Real-Time Groupware. In Proceedings

of ECSCW 2001, pages 299–318, Bonn, Germany.

Johansen, R. (1988). GroupWare: Computer Support for

Business Teams. The Free Press.

Sarvas, R. and Frohlich, D. M. (2011). From Snapshots

to Social Media - The Changing Picture of Domestic

Photography. Springer.

Cost-effectiveWeb-basedMediaSynchronizationSchemesforReal-timeDistributedGroupware

153

Stokking, H., van Deventer, M. O., Niamut, O., Walraven,

F., and Mekuria, R. (2010). IPTV Inter-Destination

Synchronization: A Network-Based Approach. In

Proceedings of ICIN 2010, pages 1–6, Berlin, Ger-

many.

Wijnants, M., Dierckx, J., Quax, P., and Lamotte, W.

(2012a). synchronous MediaSharing: Social and

Communal Media Consumption for Geographically

Dispersed Users. In Proceedings of MMSys 2012,

pages 107–112, Chapel Hill, NC, USA.

Wijnants, M., Lamotte, W., De Meulenaere, J., and Van den

Broeck, W. (2012b). Qualitative Assessment of Con-

temporary Media Sharing Practices and Their Rela-

tionship to the sMS Platform. In Proceedings of SAM

2012, pages 31–36, Nara, Japan.

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

154