Service
LuizEduardoLeite,RenataAlves,GuidoLemos,andThaisBatista
InformaticsDepartment-DIMAp
FederalUniversityofRioGrandedoNorte-UFRN
fleduardo, renata, guido, thaisg@natalnet.br
http://www.natalnet.br
Abstract. Mostsolutionsproposedtoimplementaudioandvideodis-
tributionserviceshavebeendesignedforspecicinfrastructuresorhave
been tailored to specic application requirements, such as stream and
clients typeswhichwill be supportedby the service. Other important
aspectinthiscontext isthat theperformanceof distributedservicesis
becomingincreasingly variable dueto changingload patternsand user
mobility.ThispaperpresentstheDynamicVideoDistributionService-
DynaVideo. Theservice may be designed to distribute videoina way
that is independent of the video format and to interact withdierent
typesofclients.ThemainfeatureofDynaVideoistheability tocong-
uretheservicedynamicallytoaspecicdemand.
1 Introduction
The cost reduction of high-speed networks, the development of powerful and
cheapermicroprocessorsand theconsolidationofaudioandvideostandardsto
applications such asDigitalTV, VideoonDemand,High Denition Television
and InteractiveTV are factors that motivate thedevelopment of video distri-
bution servicesoverdigitalnetworks,such asthe Internet.This paperpresents
theDynamicVideoDistributionService-DynaVideo.Theserviceisdesignedto
distributevideoinawaythatisindependentofthevideoformatandtointeract
with dierenttypesofclient.Theservice maybeused todistribute videoover
anydigitalnetwork,however,itisfocusedontheInternet. Themain featureof
DynaVideo is theability to congure theservice dynamically to aspecic de-
mand.Applicationsthatdealwithvideodistribution,such asbroadcastdigital
television,normallyhavetodealwithabruptvariationsonitsdemand.Thenum-
ber,typeandlocationofclientsoftheservicecanvaryrapidily.Thiscouldoccur
everytime thebroadcastofaninteresting programmestarts.Nowadays,many
systemscandistributevideooverdigitalnetworksliketheInternet.RealSystem
of the Real Networks [5] encodes the video streams in many formats, but its
focusisonthesupportofitsproprietaryformatRM.Thissystemmaytransmit
videowithIP Multicast,TCP,UDPorHTTP.TheMicrosoftWindowsMedia
mitted withUDP,TCP,HTTP/TCP orIPMulticast. TheIBMVideoCharger
[6] transports MPEG-1, MPEG-2 [4], AVI, WAV, LBR and QuickTime video
streams, using RTP[9], TCP, HTTPorIP Multicast. Once congured,distri-
bution services based on these platforms remain unchangedand cannot auto-
matically adjust congurationsto varieddemands.Thispaperisstructured as
follows:Section 2presentstheDynaVideoArchitecture; Section3discussesthe
implementationdetails oftheDynaVideocomponents;Section 4presentssome
experimentsresults.Finally,Section 5containstheconclusions.
2 Dynavideo Architecture
TheDynaVideoservicecanbedynamicallycongured.Thisisitsmainfeature.
Thisexibilityallowstheservicetoautomaticallyadjustitselftodemandvaria-
tions.Theservicecontinuallytriestondanoptimizedcongurationtorespond
to agivendemand.In DynaVideothe demand is dened bythe number,type
and location of the service clients. The target applications of the service are
Digital Television broadcastand Video on Demand. In such applications, the
demand canchangefrom afewusersto millionsof theminashort time.Fig.1
showstheDynaVideoarchitectureusing theUMLcomponentdiagram[2].
Primary Server Secundary
Server
Dyna Video Manager
Configuration
Optimizer Traffic
Monitor Fault Manager
Fig.1.DynaVideoArchitecture
TheDynaVideoManager(DM)controlstheserviceexecution.Whenclients
request connections, this module looks for a server with capacity to support
them. If it nds one, DM associates the client with this server. Otherwise, a
Secondary Server is initialized to support the client. Notice that initially the
servicepolicyistotrytoservetheclientasfastaspossible,andnottondan
optimizedcongurationtothevideodistribution.
ThePrimary Servers(PS)havedirectaccesstovideosources,whichcanbe
real time encoders orvideo le servers. PS captures a video stream from the
sourceandtransmitsittotheserviceclients.
TheSecondaryServers(SS)aredierentfromPSbecausetheydonothave
direct access to video sources. They receive the video stream from a PS and
forwardit to theservice clients, acting asareector.The main feature of the
DynaVideoSS isitsabilityto movethroughthenetwork.This way,when itis
necessarytooptimizetheserviceconguration,DMcandeterminethatacertain
eventactivatestheTraÆcMonitor (TM)[1]to ndtheroutes from theactive
serversto the client.This way, therole of TM is to create and update a data
structure, the route graph, which recordsroutes from the activeserversto the
serviceclients.
Whentheroutegraphisupdated,DMactivatestheCongurationOptimizer
(CO)moduletocomputeanoptimalcongurationoftheservice.COisexecuted
inthebackground,searchingforabettercongurationofthevideodistribution
service,consideringthecurrentdemandrepresentedbytheroutegraph.Oncea
congurationbetterthantheexistingoneis found,COrequestsDMto:
{ moveclientsfrom aserverto anotherone;
{ addordeleteSecondaryServers;
{ moveSecondaryServersfromonelocalitytoanother.
The goalis to tune the service conguration to optimize the use of trans-
mission, processing and storage resources. Fig. 2 illustrates an example of a
reconguration, showing the evolution from a conguration with unnecessary
streamstraversinglinksandroutersoverthenetworktoanotherwherethisdoes
notoccur.OneSSisaddedandthreeclientsaretransferredfromPStoSS.The
othermodicationwasthecreationofamulticastgroupwiththreeclients.This
optimizationtakesintoaccountthatR2doesnotsupportmulticast,sotheonly
waytoeliminateunnecessarytransmissionsin theroutethat traversesR2is to
useaSS.
Finally, the Fault Manager (FM) goalis to identify failures in the service
componentsandtoarrangereplacementsthroughaservicereconguration.For
example,ifaserverfails,FMdetectsthiseventandasksDMtomoveitsclients
toother servers.
C R2
R1
C C R3
C C C
PS
C
7 3
3 1
1 1 1 1 1 1
R2
R1
C R3 PS
3 1
1 1
C SS
C C
C C C
1
1 1 1
1
Fig.2.DynaVideoRecongurationExample
Inthefollowingsections,wediscussthespecicationandimplementationof
DM, PS, and SSModules. The TM module wasdescribedin [1]. CO and FM
3.1 DynaVideo Manager
TheDynaVideoManager(DM)providesmechanismsto:
{ RegisterPrimary Servers;
{ Addanddelete clients;
{ Add,delete, andmoveSecondaryServers;
{ Selectaprimaryorsecondaryservertoattend aclientrequest.
DMisdividedinto threeparts:ServerInterface,Client InterfaceandMan-
agerController.TheServer Interfacefunction is tocontrol thecommunication
betweenDM andthemodules SSandPS. TheClient Interfacereceivesacon-
nectionrequestandforwardsittotheproperserver(primaryorsecondary).The
Manager Controller enablesservicemanagementby controllingwhich serveris
activeandwhichserversupportseachclient.Thisclassupdatesthedatastruc-
tures ServerTable, ClientTypeTable and ServiceConguration through the exe-
cutionoftheroutinesServerRegistration(),AddClient(),AddServer(),Primary-
ServerRegister(), DeleteClient()and MoveServer().The choice ofthe serverto
support anew clientis made by the SelectServer() routine, which searches at
the ServiceConguration tree (similarto the treeshownin Fig.2) fora server
withcapacitytosupportthenewclient.
OneofthetargetapplicationoftheDynaVideoserviceistodistributeTele-
visionvideo.Consideringthisapplicationasanexample,whenauserwantsto
playavideo usinga third partplayer(DynaVideoclient),he must dothe fol-
lowingactions: theusermustaccess aWeb pageandselectaTV channellink.
Attheclientbrowser, anappletwill beexecutedto sendaStreamRequest() to
DynaVideo Manager, providing the properinformation about thevideoplayer
that will be used. DM, executing the SelectServer() method, searches for an
appropriate serverto support theclient. Ifthere isone, it is selected andAd-
dClient() is executed to associate this server with the client. Then, the video
stream beginsto betransmitted to theclient.Thetransmissionends whenthe
clientsendsaStopStream()toDM.Inresponse,DMremovestheclientfromthe
service with the executionof the RemoveClient() method, as shown in Fig.3.
Thesamegureillustratesasituation in which thereis notanavailable server
tosupportanewclient.Inthiscase,DMinitializesaSecondaryServertoserve
thenewclient.
3.2 Primary Server
ThePrimaryServer(PS)canbeconguredtomeetserviceneeds(videoformat,
transmission rate and protocol). PS supports dierent kinds of clients (forin-
stance,MicrosoftMediaPlayer,Real PlayerandMTV).Theinterfacebetween
PSand thedatasourcesis basedin twoclasses:SourceManagerand SourceIn-
Client : Client Manager : Manager Secondary Server : Secondary Server Primary Server :
Primary Server
Stop Receive Stream( )
Delete Client( ) Stop Receive Stream( )
PrimaryServerRegister( )
Stream Request( )
Select Server( )
Add Server( ) Add Client( ) Stream Request( )
Add Client( ) Select Server( )
Delete Client( )
Fig.3.AddClientCaseSequenceDiagram
ismorethanonedatasource,aninstanceofeachoftheseclassesisusedforeach
source.TheSourceInterfaceclassreceivesvideodatasegmentsandstoresthem
inaninstanceoftheDataBuerclass,invokingthePutDataOnBuer()method
oftheMainManagerclass.TheSourceManagerclassacquiresparametersofthe
data source. For example, if it is a TCP transmitter, the jitter is measured
and reported to the MainManager class through the SetParameter() routine.
TheMainManagerclasscontrolstheexchangeofinformationbetweentheother
classesofPS.ItcontrolsdatainsertionandrecoveryinaDataBuerobject,us-
ingthemethodsPutDataOnBuer()andGetDataFromBuer(). Thisclassalso
storesandretrievesthePSparametersconguredbytheserviceadministratoror
dened bysomeotherobject,throughtheSetParameter()andGetParameter()
routines.TheMainManagerclassinterpretsandexecutescommandsthroughthe
Execute() routineand adds and removesclientsusing AddClient()and Delete-
Client() routines.
TheDataBuerclasscontains,in additiontoabuerusedtostorethedata
stream,mechanismsthatprovidemutualexclusionbetweenbueraccessingob-
jects.This class hasalso atimestampthat indicates thetime of datainsertion
into the buer. This feature allows the classes which access objects to decide
whether theywill usethose data ornot.Theinterfacebetween theservicead-
ministrator and theMainManager class,which enablesthesystemadministra-
cutessome,andforwardsotherstoSS.EachuserofPSmustbeassociatedwith
theclassesClientManagerandClientInterface.ClientManagercontrolseachnew
client'sconnectionwithouttheinterventionoftheadministrator,negotiatingits
initial parameters.It also notiesthe connectionordisconnection of clients to
theMainManager class. TheClientManager classcontrols streamtransmission
to the clientsand canrenegotiatethe initial transmission parameters. Forex-
ample,itcanchangeaclientconnectionfrompoint-to-pointtomulticastinreal
time. ClientInterfaceclass controlsaccess todata storedin theDataBuer ob-
ject,invokingtheGetDataFromBuer()methodoftheMainManagerclass.The
ClientInterfaceclassalsoadjuststhedatastreamformat,inconformitywithre-
quirementsoftheclienttypeassociatedwiththeclass,andtransmitsthedata.
Forinstance,thisclassadaptsMPEGstreamstoallowtheirtransmissionusing
theRTPprotocol.
PrimaryServerwasimplementedtoallowtransmissionofMPEGstreamsto
the followingclients: MTV(MPEG-1 using TCP, UDP, HTTP and IP Multi-
cast);VideoLan (MPEG-2using UDP);Windows Media Player(MPEG-1 and
MPEG-2usingHTTP);RealAudio(MPEG-1usingHTTP)andJMF(MPEG-1
usingRTP).IntheexperimentsdoneatNatalNetLaboratoryatUFRN,MPEG
streams were obtained in real time from an Apollo capture card. The card is
installed in aPC Pentium II 400 with 64 MB of RAM and aMicrosoft Win-
dowsNT4.0operatingsystem.ANamedPipewithan8MBbuerwascreated.
TheApollo softwarewascongured towrite thevideostreaminto thepipe. A
programnamedStreamerwasimplementedusingtwothreads.Onethreadwaits
for connection requests and acceptsthem if there is no other client (PS) con-
nected. The other onecontinuesto read the MPEGstream from thepipe and
transmitsittoPSusingaTCPdataconnection.WhenthebueroftheNamed
Pipebecomesfull,thestreameremptiesthebuerandnotiesPSusingaTCP
signalingconnection.
PSwasimplementedusing C++ andwasinstalledin aLinuxplatform. As
alreadymentioned, SourceInterfaceclass wasimplementedto receivethe video
stream.SourceManagerclassreceivescontroldatafromtheStreamer.SourceIn-
terface object stores the data segments of the video stream in a DataBuer
object,usingthePutDataOnBuer()methodoftheMainManagerclass.Client-
ManagerandClientInterfaceclasseswerespeciedandimplementedinadier-
entwayforeachprotocolsupportedbyPS;
To transmitMPEG-1 streamsusing theTCP protocol,theClientManager
class implementation hasamain method that remainsblockeduntil itreceives
aconnectionrequest. Whenaconnectionrequestarrives,it isaccepted,itsde-
scriptoris placedin await list andarequest issenttotheMainManager class
to insertanewclient throughthe AddClient()method. After this,themethod
remainsblocked,waitingfornewrequests;
TheClientInterfaceclasshasamainmethodthatreadsdatafromthebuer
and sends them to all clients whose descriptors are in a send list. If it is not
client.Ifthereissomeclientinthewaitlist,themethodsearchesforanMPEG
sequence initial code. When this code is found, the stream is sent to all the
clientswhose descriptors are in the wait list and these descriptionsare moved
from thewaitlist to thetransmission list.Then themethodreturnsto reading
thebuer,restartingthewholeprocess;
TotransmitMPEG-1streamsusingtheHTTPprotocol,theClientManager
classwasimplementedinasimilarwaytothoseusedforTCPtransmission.The
onlydierenceisthatbeforeinsertingaclientinthewaitlist,ahandshakeusing
HTTPprotocolisperformed.Duringthishandshake,theserverusestheheader
elds"Pragma:no-cache"and"Cache-Control:no-cache"totelltheclientthat
the content must not be cached. The format of the stream is set up through
theheadereld "Content-Type:video/mpeg".Thelengthinbytesof thevideo
le is set up in the eld "Content-Length: 45000000". This eld is necessary
andmustbeconguredwithahighvaluebecausesomeplayersstartvideoand
audio execution only when the le is completely loaded. ClientInterface class
wasimplementedin asimilarwaytothoseusedwithTCPprotocol;
TotransmitMPEG-1using UDPprotocol,ClientManager class was imple-
mented to allowinsertion and removalof clients. When a client is inserted, a
socket is createdto it and its identier is inserted in a transmission list. The
ClientInterfaceclasshasamethod thatreadsdatafromthebuerandsendsit
toalltheclientswhoseidentiersareinthetransmissionlist.Fortransmissions
of MPEG-1using IPMulticast, the ClientManager and ClientInterface classes
are similar to those used for a UDP transmission. The only dierence is that
theClientManager classreceivesaclassD IPaddress,insteadof anIPunicast
address;
Totransmit MPEG-1videostreams usingthe RTPtransport protocol,the
ClientManager class was implemented in asimilar way to those used forUDP
transmission.The ClientInterface classhas amethodthat reads datafrom the
buerandscansitinordertoidentifythedatastructuresofMPEGstandardas
wellassomeMPEGFramesheadereldswhosevaluesareplacedinspecicRTP
permanent header elds. In this way, MPEG-1 video is packed in conformity
to the rules posed in [10].To transmit MPEG-2 streams, part of the code of
VideoLan Server [8] was used to produce the transmission packets. The code
wasadaptedtoreadastreamfromthebuerandtosendittoaClientInterface
object.One ClientInterface class was implementedto receiveVideoLan Server
streams,insteadofreadingitfromthebuer.
3.3 Secondary Server
Oneof themain features of DynaVideois itsabilityto adjust theservice con-
guration dynamically. The ideais to identify network links with unnecessary
connectionstotrytoeliminatethem.Whenitisnotpossibletousemulticast,a
goodsolutionistoinstantiateSecondaryServers(SS)agents.SShastwoclasses.
Thecontroller class interpretscommands receivedfrom DMrequiring:to start
mands aresentbyDMin Protocol Data Units. Each commandhasacodeand
optionalinformationsuchastheclientIPandportnumber.TheStreamerclass
receivesthevideostreamfromPSandsendsittotheclientsintheClientTable.
SSisstartedthroughanAgentDispatcher,whichisresponsibleforthecreation,
destruction, cloning,movingand forwardingcommands to SS.SS presentsthe
followingmethods:
{ AddClient: controller addsan IPaddressand anassociated port in Client-
Table.Tosend streams,SSscans thistable.
{ DeleteClient:controllerremovestheIPaddressandtheportfromtheClient-
Table.
{ StartServer: controller requests SS to wait for UDP packets from the PS.
WhenSSreceivesapacket,itscanstheclientvectorinordertoforwardthis
packet.
{ MoveServer: controller requests SS to stop sending streams. It moves SS
(withallitsclients)tothelocationdeterminedbyDM.
{ CloneServer:acopyofanagentiscreatedinanothercontext.
{ StopServer:controllerrequestsSStostopsendingstreams.It endstheexe-
cutionofanagent.
{ DecodeCommand:controllerreceives,interpretsandexecutesthecommands
sentbyDM.
TovalidatetheSSdesign,wehaveimplementeditusing twodierentenvi-
ronments:IBMAglets[14] andAgentLua[11].
Aglet One implementation of SS was made using the Aglet library [14], de-
veloped by IBM. This library is composed of aset of classes written in Java.
These classeshavemethods thatallowtheagenttomoveor to clone fromone
execution context to another (dispatch/clone) and to be extended with other
functions. Tahiti [14] is one application that implements the Aglet execution
contextconceptandwasusedinthis work.
TheSS Aglet agent hastwoclasses: the Controller and the Streamer. The
Controller usesthe methods inherited from theAglet classto move(dispatch)
or toclone(clone)theagentto anothercontext.WhenanAglet needsto goto
anotherplace,themethodOnDispatchisexecutedtopreparetheAglettotravel.
ThismethodcallsStopStreamfrom theStreamerclass.Whentheagentarrives
atitstarget,itexecutesthemethodOnArrivalthat askestheStreamertoStart
Stream.TheStreamerstartsto receivethevideostream fromthePSandsends
ittothesamelistofclientsthatithadattheoriginalplace.TostartanewSS,
anAgentDispatchermustberunning.WhenitreceivesacommandfromDMto
start anagentin anotherplace, it clonesitself to that place. ThenewSS will,
then, use thecontroller to communicate withDM and receivecommands such
asAdd ClientorDeleteClient. Theclass StreamerreceivesPDUsfromPSand
Agent Lualibrary (aLua) [11].The aLuadistributed programmingmechanism
isan event-drivenextension oftheinterpretedlanguageLua[12].It oerssup-
port to send messagesto remoteprocesses containingcodesto be executed at
destination.InaLua, each agentis anindependentprocessthat communicates
with another agent through asynchronous messages. This mechanism has two
important features. It is a non-blocking one, once it uses an event-driven ap-
proachandconsiderseacheventasanatomicblockthatmustbeexecutedasa
whole.Since aLuaruns in an interpretedenvironment,it is easyto modifySS
whenevernecessarywithoutdisturbingotherDynaVideomodules.This feature
introducesexibilitytotheSSimplementation.
Verify_Control_Socket()
Verify_Data_Socket()
Receive_Data()
Decode_Command()
Execute_Command() Read_Stream()
Send_Stream() [Able to Read]
[Able to Read]
Fig.4.SSActivityDiagraminanaLuaEnviroment
TheSSinitializationintheaLuaenvironmenthappensinthisway.Firstly,it
isnecessarytoimplementacomponentthatactsasanagentdispatcher. Then,
DMaskstheagentdispatchertoprepareexecutioncontexts,bysendingtoitthe
command Conf (address). In response to this command, the agent dispatcher
issuesaspawncommandtotherespectiveaddress.Afterthis,anaLuaenviron-
mentbecomesreadyin thenewlocation. Inorder totriggertheexecutionofa
SS,DMsendsanactivatecommandtotheagentdispatcher.Inresponse,itsends
the Lua code of the secondaryserver to thenewly createdaLua environment.
Whenthecodeisreceived,itbeginstobeexecuted.
TheactivitydiagramshowninFig.4describestheSSimplementationusing
aLua.Aninniteloopveriesifthereare,inacontrolsocket,commandsavailable
forreading.Inthiscase,thecommandsaredecodedandexecuted.Italsoveries
if there are, in adata socket,data available for reading.In this case, it sends
themto alltheclientslistedin theclienttable.
To move an SS from a location to another, DM asks the agent dispatcher
to initializea secondary servercode in the new location. When the sentcode
is running,itadds alltheclientsofthe oldlocationin thenewone.Then, the
manager orders the primary serverto stop sending videoto the old location,
andtobeginsendingittothenewone.Andnalizestheagentbeingmoved,by
Inorderto testtheperformanceoftheDynaVideoservicewedidsomeexperi-
mentsonthefollowingscenarios.ThePrimary Server(PS)wasconguredina
PCPentiumMMX300with128MbRAMmemory,a100MbpsEthernetcard
and Linux operating system. A 4Mbps real time MPEG-2 stream wasgener-
ated and transmitted from the streamerto PS.This stream wasgenerated by
an Apollo card installed in a PC Pentium II 400 with 64 MB RAM memory
and with Microsoft WindowsNT 4.0 operating system.The utilization of the
link thatconnectsPSto anIBM8265Switch,whenPSwastransmittingUDP
datagramstoamulticastaddress,was9.5%(9.5Mbps).Sinceavideostreamwas
being generated at aconstant rateof 4Mbps, the reception and transmission
of this stream consume 8Mbps, in other words, 8% of the band.Considering
thatnootherapplicationwasusingthelinkatthatmoment,wehaveconcluded
that 1.5 % of the band wasconsumed by the overhead of transport, link and
network protocols. In another experiment, a PS was congured in a PC Pen-
tium III 600with 128 Mb RAMmemory, 100Mbps Ethernet card and Linux
operatingsystem.Thisserverreceiveda4MbpsMPEG-1videostreamdirectly
fromthestreamerandtransmittedittotwenty(20)MTVclientsusingtheUDP
protocol.ThisscenarioisillustratedbytherstpartofFig.5.Inthiscase,the
utilization of the link that interconnects PS to the network reaches 100%. To
provethefeasibilityoftheSSconcept,wemoveanSStoamachineattheLCC
network. In this scenario (second part of Fig. 5), we can serve 29 clients: PS
transmitting to 19 clients and to SS, and SS transmittingto 10 clients. With
thisexperiment,weconrmthescalabilityof theDynaVideoapproach.
SW NatalNet SW PS
C1
C3
Router NatalNet
Router LCC
LCC
C1
C17
LCC LCC
SW NatalNet SW PS
C1
C3
Router NatalNet
Router
C1
C26
SS
Fig.5.DynaVideoserviceexperimentation
The DynaVideo service was tested in a local network with the following
clients:MTV(MPEG-1usingTCP,UDP, HTTPandIPMulticast),VideoLan
(MPEG-2 using UDP), Windows Media Player (MPEG-1 and MPEG-2 using
HTTP), RealAudio(MPEG-1 using HTTP), and JMF(MPEG-1 using RTP).
MTVclient VLCclient
videobeingexhibited byanMTVclient.Fig.7showsanMPEG-2videobeing
exhibitedbyaVideoLanclient.
5 Conclusions
This paperhaspresentedthearchitecture andimplementationofthe Dynamic
VideoDistributionService (DynaVideo) designedfor genericdatacommunica-
tionenvironments,supportingdierentvideoformatsanddierentclienttypes.
In this paper, we have described the following DynaVideo components: Dy-
navideo Manager that controls the serviceexecution; Primary Serverthat has
direct access to videosourcesand whosefunction isto capture avideostream
from thesourceandto transmititto theserviceclients;andSecondaryServer
thatactslikeareector,receivingthevideostreamfromaPrimaryServerand
forwardingittotheserviceclients.
ThemainfeatureoftheSecondaryServeristhatitcanmovethroughthenet-
work.Thisallowsthedynamicrecongurationoftheservice.Theimportanceof
dynamic reconguration of videodistribution systemsis also discussedin [13].
This report proposes an infrastructure to distribute video and uses agents to
update and to x bugs in the code of the replicas. Other works [15][16] have
adopted the replication idea, but donot providesupport to service recongu-
rationduringrealtimevideotransmissions.DynaVideoallowsthetransmission
of MPEGstreamsto theMTVclients(MPEG-1 usingTCP,UDP, HTTPand
IPMulticast),VideoLanclients(MPEG-2usingUDP),WindowsMedia Player
clients(MPEG-1 andMPEG-2using HTTP), RealAudioclients(MPEG-1 us-
ing HTTP) and JMF clients (MPEG-1 using RTP). In theexperiments done,
thevideoreceivedbytheseclientswasat goodquality.Intheimplementation,
we have adopted aconguration-based approach to the DynaVideo Manager.
ThismoduleintegratestheothermodulesofDynaVideoandactsasamediator,
sending and forwardingcommands to other modules. The conguration-based
approachfacilitatesthechangeofonemodulewithoutdisturbingtheothers.This
twoimplementations.OneoftheimplementationusestheAgletlibrary,anIBM
product.TheotheroneusesaLua,anevent-drivenmechanismthatoerssupport
tomoveprocesses.Theimplementationsvalidatedthefeasibilityoftheapproach,
whichisagoodalternativeto servicesdealingwithunstabledemands,likeTV
distribution. The implementation of the TraÆc Monitor module was done in
anotherworkand itisdescribedin [1].Currently, theConguration Optimizer
andtheFailManagermodules areunderdevelopment.
References
1. Madruga,M.,Batista,T.,Lemos,G.:SMTA:UmSistemaparaMonitoramentode
TrafegoemAplicac~esMultimdia.CLEI'2000(2000)
2. Booch,G.,Jacobson,I.,Rumbaugh,J.:TheUniedModelingLanguageforObject-
OrientedDevelopment.DocumentationSetVersion0.91 AddendumUMLUpdate
(1996).
3. Coding ofMovingPicturesand AssociatedAudioforDigital StorageMediaup to
About1,5 Mbits/s.ISO/IECInternationalStandard11172(1993).
4. Generic Coding of Moving Pictures and Associated AudioInformation. ISO/IEC
InternationalStandard13818(1994).
5. Realserver Administration Guide RealSystem G2.
http://www.real.com/serveradminguideg2.pdf(2001).
6. VideoCharger Server Key Features. VideoCharger, IBM DB2 Digital Library,
http://www-4.ibm.com/software/data/videocharger/vcserverkey.html(2000).
7. WindowsMediaTechnologies.http://www.microsoft.com/windowsmedia/ (2001).
8. VideoLan.EcoleCentraleParis,http://www.videolan.org(2001).
9. Schulzrinne,H.,Casner,S.,Frederick,R.,V.Jacobson:RTP:ATransportProtocol
for Real-TimeApplications.RFC1889(1996).
10. Homan,D.,etal.:RTPPayloadFormatforMPEG1/MPEG2Video.RFC1849
(1998).
11. Ururahy,C;Rodriguez,N.:Alua:Anevent-drivencommunicationmechanismfor
parallel anddistributedprogramming.PDCS'99,FortLauderdale,FL(1999).
12. Ierusalimschy,R,Figueiredo,L,Celes,W.:Lua-anextensibleextensionlanguage.
Software:PracticeandExperience,26(6):635-652(1996).
13. Kon,F.,Campbell,R.etal.:DynamicRecongurationofScalableInternetSystems
with Mobile Agents. Technical Report, Department of Computer Science at the
UniversityofIllinoisUrbana-Champaign(1999).
14. Lange, D., Oshima, M.: Programming and Deploying Java Mobile Agents with
Aglets.AddisonWesley(2000).
15. Parveen Kumar, L. H. Ngoh, A. L. Ananda.: A Programmable Audio/Video
StreamingFrameworkforBroadbandInfrastructures.NetworkStorageSymposium
-NetStore'99.Seattle,WA(1999).
16. Brian Noble, BenFleis, MinkyongKim, Jim Zajkowski.: Fluid Replication.Net-
workStorageSymposium-NetStore'99,Seattle,WA(1999).
