Real-Time Control and Management of Distributed Applications using IP-Multicast Peter Parnes, K˙are Synnes, Dick Schefstr¨om Lule˙a University of Technology, Department of Computer Science 971 87 Lule˙a, Sweden. fPeter.Parnes,Kare.Synnes,
[email protected]
Contact: Peter Parnes Phone: +46 920 72421 Fax: +46 920 72801 July 15, 1998
Abstract
1 Introduction
A central issue within any distributed computer environment is how to control and manage installed software and running applications. With control and management, we mean both how to make permanent changes to installed software and real-time control of running applications. This paper presents a framework for control and management of distributed applications and components using IP-multicast. The framework allows for easy and scalable control of single applications, groups of applications or parts of applications using a new agent based architecture. Messaging is done using the Control Bus and the Scalable Reliable Real-time Transfer Protocol for reliable distribution of data. The paper also presents an application called multicast Manager - mManager, a prototype Java implementation that provides a user interface to the framework. The mManager allows administrators to get an overview of currently running applications and if necessary control these applications. The framework includes support for secure messaging using public key cryptography to target the need for user privacy and secure control. The paper presents example usage scenarios where the framework is used to create bandwidth adaptive applications and better group awareness.
A central issue in any computing environment, both in academia and industry, is how to control and manage installations of software and applications. With control and management, we mean both how to make permanent changes to installed software and how to control applications while they are running. Control in the latter case is applicable to the more and more used application family of IP-multicast [3, 9] based distributed real-time applications for primarily desktop conferencing, distance education and media broadcasts with many simultaneous users. These distributed applications usually utilize the available bandwidth more than traditional single user applications and these applications are usually more sensitive to large delay and jitter in the network. It is therefore very important that real-time media applications do not compete with each other for the available bandwidth but instead cooperate and try to utilize the bandwidth in the best possible manner.
1.1 The mStar Environment
The mStar environment [15] is an environment for scalable and effective distribution of real-time media and data Keywords: Distributed Systems and Applications between a large number of users. mStar is a shared enManagement, Intelligent Agent Technology, Integration vironment that can be used for e.g. net-based learning of Network Control and Management, Quality of Service (distance-education) and collaborative team-work. It inManagement, Multimedia and Telecommunication Ser- cludes support for a number of different media including audio, video, shared whiteboard, distributed presentations vice Management, IP-Multicast, Java using the World Wide Web and much more. It also sup This work was supported by the Centre for Distance-spanning Tech- ports on-demand recording and playback of sessions usnology (CDT), Lule˙a, Sweden ing either unicast or IP-multicast. 1
1.3 Background Information
This paper presents and discusses an architecture for management and control or distributed applications. It also presents a prototype implementation and an example usage scenario. The rest of this section presents an overview of the current problems and related work. Section 2 presents the new control and management framework. Section 3 presents the prototype interface to the framework, mManager. Section 4 presents how the framework can be used. Section 5 presents implementation issues and future work and the paper concludes with a summary and discussion in section 6.
IP-Multicast Applications Traditionally, distribution of multimedia data on the Internet to a group of users have been done using unicast, either by each multimedia application sending one exact copy to every receiver or by pushing the problem into the network and using a so called reflector which duplicates streams to every registered receiver. This means that duplicate data will be sent if the path between the sender and its receivers share common links in the network.
The power of IP-multicast is that data is only copied in the network where needed when sending the same data 1.2 Overview of Current Problems to several different receiving hosts. IP-multicast traffic is sent using UDP which is best-effort and in turn means To be able to monitor and control system environments that packets can be lost in the the network. This might be a it is necessary to get feedback on what applications users problem i control situations as the manager wants to be asare currently running, which version of the specific applisured that sent control messages actually are delivered to cations they are running, and the current configuration of the destination. This problem is further discussed in secthese applications. These questions are very general but it tion 2.2. A drawback with IP-multicast is that it requires still might be a problem to find out the answers. support from routers in the network to handle this special When a distributed symmetric desktop conferencing kind of traffic. If the routers in question are fairly new, it application, such as the mStar environment, is deployed might be simply a question of turning on the support in the in a large organization a number of new management and router software. To summarize, the IP-multicast solution control issues evolve. The administrators need to be able saves large amount of bandwidth in the network. to get information about and control: which users are part of which conferencing sessions, which media in each session do they currently have active (i.e. which media are they currently receiving), and if the user is currently transmitting any data within a session and then with which set- Real-time Transfer Protocol - RTP tings (e.g for video transmission the settings in question could be the bandwidth currently used, frames per second The Real-time Transfer Protocol - RTP [18] is designed or codec/video-format). for real-time traffic over both Intra- and Internets. RTP If this information is available it will allow the admin- functions include loss detection for quality estimation and istrator to control both session membership (e.g. kick out rate adaption, sequencing of data, intra- and intermedia unauthorized members) and the total bandwidth used by synchronization, source identification, and basic memthis group of applications. This means that the network bership information. RTP is designed to operate on any administrators can control the total amount of bandwidth kind of network-protocol and is therefore completely selfused by each user and session explicitly. contained, meaning that it does not depend on any inforIf remote control of application is available administra- mation in the lower levels of the network model. tors should be able to control several instances of the same RTP actually consists of two different protocols, the application at once. This control should of course be done RTP that transports the payload data and the Real-time as efficiently and quickly as possible. Transfer Control Protocol - RTCP, which exchange metainformation about the current session. The protocols operate on two separated channels where transmission is of best-effort quality, meaning that packets can be lost withSummary of Problems out retransmission. All members on the RTCP-channel These problems can be divided into two major groups, send regular messages about how much data they have namely information reports from users and remote con- sent (if any) and how well the data on the RTP-channel trol of the applications. This paper focuses on presenting is being received. This information can be used to detect a new framework for solving these problems in the con- packet-loss and notify senders to adapt their transmissiontext of distributed applications. rates to the current packet-loss. 2
1.4 Related Work
hosts for e.g. negotiation of access to the audio device or voice switched video.
Simple Network Control Protocol - SNMP The Simple Network Control Protocol - SNMP [19, 21] is designed for control of network elements and basic applications. It is designed with a ’polling’ architecture in mind meaning that the managing software have to request information from each element to be monitored. This architecture allows managers to get information from a monitored object and set variables in that object. SNMP includes support for so called trap’s where a manager can request to be notified when some predefined situation occurs. A restriction with these trap’s are that they cannot be defined dynamically but the manager has to rely on predefined trap’s. Note that although this trap mechanism exists the normally used part of the SNMP mechanism is still the “get/set” functionality. Another restriction with SNMP is that it does not allow managers to tell the managed object to “work” by invoking methods in the object.
Java Specific Platforms for Distributed Applications There exits a number of proposals for Java based architectures for distributed applications [1, 8, 10]. Some are very promising and flexible but they all make one large assumption on the their programmatic environment and that is that they are very tightly integrated with the Java programming language and its runtime environment, i.e. they assume that they have access to features that are very specific to the Java environment, such as Java-events and serialization (binary representation of Java runtime objects). This assumption makes these frameworks virtually unusable in other environments.
2 The Control and Management Framework
As presented earlier there are a number of problems involved in how to control and manage real-time distributed The designers of the Service Management System - applications. This section presents a new proposed control SMS [6] argue that the poll-architecture of SNMP causes and management framework for solving these problems. managers to often notice problems too late as the object in trouble cannot notify its manager about its condition. The creators of the SMS system try to approach this prob- 2.1 Information Reports lem by creating an architecture where each managed obTo be able to request information from currently running ject is encapsulated by a SMS wrapper which marshals applications there must exist a platform that allows for recommands to and from the managed object. The wrapports to be sent in a scalable way. With scalable, we mean per has a SMS agent to aid it with automatic handling of that the solution found should be usable both within sescertain situations. This SMS agent can be controlled by a sions with a few users and within sessions with a large set of rules (defined using the so called Service Managenumber of users. This includes both the total amount of ment Agent Programming language - SMAP) to react on used bandwidth and the number of applications that can information provided by the SMS wrapper. use the platform for reporting at the same time. If a large Although this architecture seems promising it does not number of applications send reports at the same time, moinclude support for resource discovery, information rementarily a larger amount of bandwidth will be used as porting and scalable control of large groups of applicathe total number of messages increases linearly with the tions. number of users. The obvious solution is that every application should not send its report at the same time as The Conference Control Channel Protocol - CCCP every other application, but instead utilize a back-off and delay method based on the available bandwidth, the cur[5] presents the Conference Control Channel Protocol rent number of members in the session and other reports CCCP which is a protocol for control of distributed mulreceived. timedia applications. It consists of a text based message Within the Real-time Transfer Control Protocol (see protocol for primarily control. The CCCP is similar to the section 1.3) there already exists a mechanism for handling work presented in this paper but differs in that we focus reporting within large groups. The basic concept of this on a wider range of applications than just the group of conferencing applications and not only real-time control method is that a single application calculates how long it should wait until it should send a report based on the but also scalable reporting of information and permanent number of other members it has seen so far (i.e. members changes to installed software. that have earlier sent a report 1) and the available band[11] presents a similar message platform but that one is width within the session. The total available bandwidth even more constrained and only target the problem of how 1 Reports are sent to everybody within the group using IP-multicast. to communicate between similar applications on the same The Service Management System - SMS
3
for a session is normally specified when the application is started and the total control bandwidth is specified as maximum 5% of the session bandwidth. This means that independently of the number of members in a session a constant maximum bandwidth will be used for control information. RTCP also supports report extensions where applications can add information that they need to report without breaking the already existing protocol. This reporting system can both be used for regular reports where applications report predefined information in regular intervals and for on-demand reports where applications report information based on requests. These two cases can also be combined where a manager requests applications to include some information that changes often in each regular report sent. This could be used for retrieving the amount of bandwidth currently being used by each member within the session. To allow for administrator mobility all reports are always sent to the whole group. This allows for different manager applications to be active within the same session at the same time without requiring that information is duplicated in the network (by different applications requesting the same information). This means that administrators can monitor and control their system from any host within the network.
message formats presented in [5] and [11]. Each message is text based and a message consists of four sections: 1. The from section which identifies the sender uniquely. The address field consists of four parts: Host / CB-id / Agent-type / Instance. 2. The to section which identifies the destination of the message. A message can be directed to a single agent, all applications within a session or a group of agents independently of which application they reside in. The address format is the same as for the from section with the exception that any part can be replaced with a wild-card. This allows for simple and dynamic addressing of messages. 3. The message id section which together with the from section forms a unique identifier within the session. This section consist of a sequence number that is increased for each transmitted message. 4. The message section which contains the message it self.
The traffic on the CB can be both one-way and twoways, i.e. messages can be of the information-type where an agent is announcing something and is not expecting any response or it can be a request for more information where the requesting agent is expecting a response. To simplify the protocol only text based arguments and 2.2 Control values are allowed. If a specific application needs another A pre-requirement is that the system should be able to type, then that application has to take care of conversion to control both single applications and groups of applica- and from a text representation. Experience with the contions. Of course, the latter includes that if the same param- trol bus have shown that the advantage and simplification eter is to be sent to all the applications only one message of only using text messages is larger that then overhead of should be sent and not one specific and identical message occasionally converting values to and from a textual repto each single instance. This leads to that messages should resentation. The use of a simple and pure textual message format be sent using IP-multicast within the group just as the earmakes it easier to create a platform independent messaglier discussed reports. ing system. It also makes it easier to integrate the control bus into existing applications. Note, that the control bus The Control Bus - CB is not tied into its current transport mechanism but it is designed to be used on any underlying reliable transport To allow for easy messaging, a message and control pro- protocol. tocol is needed. For this, the Control Bus - CB [13] was chosen. Messaging The Control Bus is designed for controlling so called agents and as well as full applications. An agent is a soft- Any control and management framework must contain a ware component that resides within an application and is set of predefined control messages for retrieval of inforresponsible for one specific task. For instance, a video- mation about other supported messages in a specific apagent would be responsible for capturing and displaying plication. Therefore the control bus interface enforces apvideo data and a database-agent would act as an interface plications to respond to a basic set of messages: to a database-engine. Numerous agents could and is norinfo-request describe: Return a description of the admally deployed within one and the same application. See dressed agent. figure 1 for an example agent setup. info-request describe-all: Return a summary of all The CB can be used for transmitting messages both supported commands. Each command can be either writewithin applications and between different instances of ap- enabled, read-enabled or both. The framework does not plications. The format of these messages are based on the separate commands from get/set of variables in an agent. 4
Net
WB Member
Audio Web Net
Agent Control Net
mWeb
Chat
Video
mManager
Web
Wave
mPlayer
Vote
mDesk
Status
Status Web Net Member
Figure 1: Some of the mStar applications and their agents. Note that the same agents are reused in different applications. A command invocation is modeled as a set (with or without arguments). alive: Return a short answer if the agent exists. This is to be used for resource discovery of active agents and applications. get-request and set-request: for activating the corresponding get and set methods in an agent. Note that the name does not have to correspond to any specific software method in the agent. The mapping is handled by the control bus implementation. Using these basic control messages more information about the agent of interest and information about which methods it supports can easily be found. Figure 2 show a number of example control bus messages.
was lost instead of one ACK per data segment received. Unfortunately, once again if the group is large and the packet was lost near the original sender, this would result in a large number of packets being sent almost simultaneously to the original sender. This is called the NACK-implosion or feedback-implosion problem [2] and is very similar to the ACK-implosion, only that it does not happen as often. A more advanced solution to this problem was proposed in the SRM [4] framework where every member of the session helps out with repairing lost traffic. The SRM framework consists of: 1. each NACK is sent to the whole group using IPmulticast and not only to the original sender; 2. if a packet was lost, the host waits a certain time period before it sends a NACK and if it “sees” a NACK for the same packet from another member it suppresses its own potential NACK;
Scalable Reliable Real-time Transfer Protocol - SRRTP As mentioned in section 1.3 a problem with using IPmulticast is that it is sent using best-effort UDP which means that packets can be lost in the network and it is up to applications to ensure that the message is really delivered. To solve this distribution problem a reliable multicast protocol is needed and the locally developed Scalable Reliable Real-time Transfer Protocol - SRRTP [12] was selected. This protocol allows for transport reliable distribution of IP-packets using IP-multicast. When using IP-multicast the problem of reliability is not as easy to solve as in the unicast case, where the sender of the data keeps track of how much data it has sent and the receiver reports back by acknowledgments, how much it has received. This works fine when only two hosts are involved, but unfortunately it does not scale to a large number of receivers as the number of acknowledgments sent back to the original sender would increase linearly with the number of receivers. This is called the ACK-implosion or feedback-implosion problem [2]. A very simple solution would be to let each member of the session just send one packet (a negative acknowledgment - NACK) to the original sender each time a packet
3. each member of a session saves the last packets seen in the session and if it sees a NACK for a packet it has earlier received and still has in its buffer, it sends this packet to the whole group. This is a so called “repair”; 4. before sending a repair the host waits a certain time period and if it sees a repair for the same packet it suppresses its own potential repair. These are just some of the general ideas of the SRM framework and there are a number other issues to take into account when implementing the SRM framework, for instance how long each host should wait before it sends a NACK or repair. An evaluation of this approach can be found in [17]. These different ideas of the SRM framework have been deployed in an extension of RTP to include functionality for reliable delivery of information to a large group of receivers. This new protocol is called Scalable Reliable Real-time Transfer Protocol - SRRTP. The reason for extending the existing RTP and not designing a completely new protocol is that functionality that is part of 5
130.240.194.245/2345/mManager/45663 */2345/net/* 7 Alive 130.240.64.42/2345/net/33664 130.240.194.245/2345/mManager/45663 73 OK 7 Alive 130.240.64.54/2345/net/883243 130.240.194.245/2345/mManager/45663 22 OK 7 Alive 130.240.64.97/2345/net/43526 130.240.194.245/2345/mManager/45663 983 OK 7 Alive 130.240.194.245/2345/mManager/45663 130.240.64.42/2345/net/33664 8 info-request describe short 130.240.64.42/2345/net/33664 130.240.194.245/2345/mManager/45663 74 info-reply 8 mStar network agent 130.240.194.245/2345/mManager/45663 */2345/audio/* 9 set-request size-ms 40 130.240.194.245/2345/mManager/45663 */2345/video/* 10 set-request fps 15
Figure 2: Example CB messages. top: resource discovery. middle: information request. bottom: invoking methods in several agents (note that no answer or acknowledgment is sent as the underlying mechanism is expected to be reliable). RTP can be reused within real-time sessions. For instance, secret key needed to generate new signatures. a SRM-based protocol have to now approximately how The predefined public key can be specified in the instalmany users there are within a session and this information lation program for automatic handling within an organizais already available within a RTP session. tion. An optional override public key can also be specified and can be used to change the normal operational key if its corresponding secret has been compromised. This 2.3 Security and Privacy Issues override key should of course be stored in a secure way It is important that not just any user that have access to the and is only to be used in very rare cases. control and management framework can control any other The same digital signatures can be used for enabling application. This is a privilege that should be reserved to privacy of reports if needed by encrypting the reported authorized users. data using the public key. This means that only the users Within the control and management framework this is that have access to the corresponding secret key can decurrently solved using public/secret key based digital sig- crypt the report and view its contents. natures [20]. Public/secret key technology means that each key is divided into a public and a secret key-part with the convenient property that the respective part cannot be calculated from the other. If a user encrypts something with the public part it can only be decrypted using the 3 The multicast Manager - mMancorresponding secret part. This can be used for digital ager signatures by calculating a digest (a unique digital summary of the data) and then encrypting it using the secret key. Anyone that have access to the public key can then Within the mStar environment an application called the decrypt the signature and compare the resulting digest to multicast Manager - mManager is currently being dea digest that is calculated locally on the data in question. signed and constructed. This application is a front end to Note that a correct signature can only be generated by usthe control and management framework. It allows a user ing the correct secret key. to retrieve information about currently running applicaA predefined public key is stored in each client applications and control these applications. For an application tion and when a control message is received the optional to be controllable by the mManager it has to contain the accompanying digital signature is verified against the precontrol bus software. Figure 3 and 4 shows snap-shots of defined public key. If the signature matches, the command parts of the current mManager user interface. is carried through and if it does not, a warning message is sent to the group warning about that there might be a viBy that the framework is IP-multicast based the mMancious user trying to break the application control scheme. ager can be started on any host in the network and any The use of digital signatures allows the messages to be number of simultaneous instances can be running at the sent in plain text and even if a message and its signature is same time. This allows for flexibility for the adminissnooped on the network, the snooper cannot do any harm trators as they will not be bound to any specific control within the session as s/he does not have the corresponding station which is normally the case in large systems. 6
Figure 3: The mManager main user interface.
Figure 4: The mManager send message dialog.
3.1 Automatic Response Control Filters
The mStar environment can be used for light-weight desktop conferencing. It allows any user that have access to the application to transmit audio and video within a session. Using the mManager, administrators can get an overview of the members of a session and they can control who within the session should be able to transmit. This can be controlled in real-time on a user by user basis.
It is not always a human person can be available to monitor the activity within an organization. To target this, mManager contains the functionality to set up automatic control response filters. These filters can be set to respond to special conditions within an installation with predefined actions. For instance, if a user suddenly starts transmitting video with a bandwidth above a specific level a control message is sent to that application to lower the allowed bandwidth. 4.1 mWeb Configuration Control These filters can also be set to trigger external programs which allows for easy extension of the control framework A real 2life example is where the mStar Web presentation system was deployed within a large organization (several with installation specific applications. hundred installations) and during a critical session broadcast a problem with the existing environment was found (due to the organizations special set-up of its computers) 4 Usage Scenarios where Web slides could not be displayed on users local 2 A system called mWeb for distributing Web based presentations using IP-multicast [16].
This section presents a number of ways of how the management and control environment can be used. 7
rently transmitting, A gets all available bandwidth allocated to it) Kbps via a control bus message. Next B and C joins and both start transmitting at the same time. The controller then lowers the bandwidth of A to 100 and sets the maximum allowed bandwidth for B and C to 150 Kbps each. After a short while the controller notices that host C is only transmitting with a bandwidth of 50 Kbps (the user selected to only transmit with this bandwidth) and there4.2 Better Quality of Service using Adap- fore increases the available bandwidth for host C to 250 Kbps. When host A later leaves the session the controller tive Applications reallocates the bandwidth from session 1 to session 2 and The framework can be used to control the maximum al- sets the maximum allowed bandwidth of C to 350 Kbps lowed bandwidth within a session when it is noticed that (note that host B is still only transmitting with a bandthe total utilization of the involved networks gets above a width of 50 Kbps). specific level. Together with automatic filters the frameThe framework can easily be used by applications to rework can be used for creating a better Quality of Service trieve information about the currently allowed maximum environment where a control process allocates bandwidth bandwidth when the application starts. to session as needed and control applications so they canInstead of building this logic for adaptive applications not utilize more network bandwidth than allowed. Ear- into the applications themselves it can easier be controlled lier this have only been possible using static configura- in real-time what policy should be used at a specific motions and control by a human operator. Now it can be ment and installation. controlled dynamically in real-time depending on other concurrent sessions. This creates a set of adaptive applications that better utilizes the available bandwidth and scales to a larger number of simultaneous users and ses- 4.3 Better Group Awareness sions as over-utilization by a greedy user/application can be prevented. The mStar environment can be used as an electronic corcomputers. The software solution was simple and found quickly but the problem was then how to spread the modified software and the new settings to all listeners. If the control and management framework had been in place at that time it would only had been a question of sending out the correct message to all active instances of the application.
ridor where every user is transmitting a low bit-rate video stream from their office. This allows for their colleagues to peak into their offices and get a view of what they are currently doing. This can be used for seeing if the other party is available or not before trying to contact him/her. It can also be used to create a better group awareness environment where users geographically separated (working in different offices or from their homes) can see if their colleagues are working as well. In the existing mStar system every user sends the amount of video decided by the user him/herself, no matter if anyone is actually viewing the video-stream or not. Using the control framework the receiving mStar instance should instead notify the other party’s application when the local user is looking on a particular stream. When the other, remote application gets notified it should Figure 5: An example adaptive application setup. increase the amount of bandwidth used for that particular Figure 5 shows an example adaptive application set-up. video stream. Further, the more users viewing the same A, B and C are hosts running multimedia applications and video stream the higher bandwidth should be allocated to X is the controller. The total bandwidth is set to 400 Kbps that stream. for all sessions. Host A belong to session 1 and hosts B The same concept can of course be used for real-time and C belong to session 2. Session 1 has 25% of the to- electronic meetings and lectures where the current numtal bandwidth allocated to it. Initially only host A is active ber of viewers controls the relative bandwidth of a specific and it is transmitting with a bandwidth of 600 Kbps which video stream. Note that this example differs in its archiis above the allowed maximum. The controller gets infor- tecture from the earlier one in that it does not have any mation about this via the regular reports and changes the central process controlling the session but instead all contransmit bandwidth of A to 400 (as nobody else is cur- trol is handled within the session itself. 8
4.4 Real-Time Control of a Recording and width used for messages as low as possible by checking if other hosts are currently sending any messages and if so Playback System delay its own potential transmission. The issue of making permanent changes to deployed software is still mostly untested (some initial support exists in the first prototype but nothing final). With the framework in place it also would be interesting to pursue the issue of software updates by distributing software components using IP-multicast for dynamic ondemand update of software.
The framework can be used for controlling the multicast Media On Demand system - mMOD [14] which is a recording and playback system for IP-multicast sessions. It allows a user to start playback of earlier recorded sessions using a WWW interface and during the playback control the player in a number of ways including simple VCR functionality but also jump between book-marks, filters streams and transcode the media being played back. This interaction is made very easy using the framework presented in this paper. Different clients can be developed and deployed independently from each other and without need to change the server application.
6 Summary and Conclusions This paper presents a framework for control and management of software applications. It allows applications to distribute messages in a scalable way, with regard to both the number of applications currently running and the available control bandwidth. This is done using IPmulticast, a reliable multicast protocol (SRRTP) and a messaging platform called the Control Bus (CB). The novel usage of IP-multicast for management and control creates a mobile and scalable framework that can be used for a number of different applications. To utilize the control and management framework and administrate running applications, a program called multicast Manager - mManager is currently being developed. The mManager gives the administrators an overview over currently running applications and allows administrators to control these applications. To protect control of applications from vicious users the framework includes support for digital signatures where each control message can be accompanied by a signature. We presented how the framework can be used for creating better group awareness in a distributed real-time environment. Further, it was presented how the environment can be used to create a better Quality-of-Service environment for distributed media applications where bandwidth is dynamically allocated between active sessions and the total amount of used bandwidth is controlled automatically by a control process. It was also described how the same framework is used for controlling an IP-multicast real-time recording and playback system. These different usage scenarios show that the framework is flexible and can be used for a number of different applications. The framework is currently being designed and implemented so it is too early to draw any final conclusions about its practical usability but initial prototypes show that it works and is powerful (note that the CB and the SRRTP have both been used in large scale earlier in other contexts and applications). The work presented in this paper is based on requests from both academia and industry. We believe that this framework simplifies the administration and control of
5 Implementation and Future Work The control and management framework and the mManager is currently being implemented using the Java programming language. The programmatic interface to the control bus is a simple interface where each agent registers which methods it wants to export. The registration includes a textual description of what the access method does.
5.1 Future Work An open issue is how changes to an active instance of a program should be presented to the user and more precisely which changes are significant to notify the user about. For instance, if a controller requests an application to lower the bandwidth for its outgoing video stream by 1 Kbps. Should this cause the user to be notified or not? It all depends on the current bandwidth being used. In the current implementation of the framework it is left to the application to decide which changes should result in the user being notified. The security system is still in its infancy and have to be further investigated. Specially the interface to the agent of how to specify who has access to which methods and information have to be further investigated and defined. This is a delicate problem as programmers want a simple but at the same time powerful interface. The current automatic response filters are very simple and limited due to the lack of a good and simple action specification method. Initial interfaces of interest are SMAP [6] and the autonomous agent services of the Java Dynamic Management Kit [7]. Note that the target is still to create an environment independent framework, i.e. one that is not dependent of the Java runtime environment. Another open issue is flow control of messages. In the current implementation messages are sent as soon as possible. Instead the framework should try to keep the band9
large software installations and real-time multimedia sessions.
[11] S: McCanne and V. Jacobson. vic: A flexible framework for packet video. In ACM Multimedia Conference, 1995.
Acknowledgments
[12] P. Parnes. Scalable Reliable Real-time Transport Protocol - SRRTP. Work in progress8.
˙ Thanks to Claes Agren (Marratech AB), Serge Lachapelle (LTU/CDT), and the people at Ericsson Data for comments, suggestions, and feedback. This work is supported by the Centre for Distancespanning Technology (CDT), Marratech AB and the Swedish National Board for Industrial and Technical Development, NUTEK.
References
[13] P. Parnes. Control Bus specification. progress9 , 1996.
Work in
[14] P. Parnes. mMOD - the multicast Media-OnDemand system. extended abstract 10 , 1997. [15] P. Parnes. The mStar Environment - Scalable Distributed Teamwork using IP Multicast. Lule˙a University of Technology, September 1997. Licentiate of Engineering Thesis.
[1] Mark Colan. Infobus 1.1 specification. Technical re- [16] P. Parnes, M. Mattsson, K. Synnes, and D. Schefport, Sun Microsystems Inc. and Lotus Development str¨om. The mWeb presentation framework. ComCorp., March 1998. URL3 . puter Networks and ISDN Systems, 29:1083–1090, September 1997. [2] J. Crowcroft and K. Paliwoda. A multicast transport protocol. In ACM SIGCCOMM, 1988.
[3] [4]
[5]
[6]
[17] S. Pingali, D. Towsley, and JF. Kurose. A comparison of sender-initiated and receiver-initiated reliable S. E. Deering. Multicast Routing in a Datagram Inmulticast protocols. In ACM SIGMETRICS Conferternetwork. PhD thesis, Stanford University, 1991. ence on Measurement and Modelling of Computer Systems, 1994. S. Floyd, V. Jacobson, S. McCanne, C. Liu, and L. Zhang. A reliable multicast framework for light[18] H. Schulzrinne, S. Casner, R. Frederick, and V. Jaweight sessions and application framing. In ACM cobson. RTP: A transport protocol for real-time apSIGCOMM, 1995. plications, 1996. IETF RFC1889. Mark Handley, Ian Wakeman, and Jon Crowcroft. [19] Protocol operations for version 2 of the Simple The Conference Control Channel Protocol (CCCP: Network Management Protocol (SNMPv2). IETF A scalabe base for building control applications. In RFC1905. ACM SIGCOMM, 1995. [20] W. Stallings. Network and Internetwork Security Y. Izumi, T. Nakai, S. Yamaguchi, and Y. Oie. DePrinciples and Practice. Prentice Hall, 1995. sign and implementation of an agent system for application service management. In Proceedings of [21] W. Richard Stevens. TCP/IP Illustrated, volume 1. ISOC INET’98, 1998. Addison-Wesley, 1996. chapter 25.
[7] Java Distributed Management Kit 2.0. Technical report, Sun Microsystems Inc., 1998. URL4 . [8] JavaSpace specification. Technical report, Sun Microsystems Inc., March 1998. URL5 . [9] V. Kumar. The MBone information web. URL6 . [10] Silvano Maffeis. iBus - the Java Intranet Software Bus. Technical report, SoftWired AG, February 1997. URL7 .
> < < overview.html> 5 6 7
3 URL:http://java.sun.com/beans/infobus/infobus-1.1.pdf 4 URL:http://wwwwswest2.sun.com/software/java-dynamic/tech-
< <
>
8 URL:http://www.cdt.luth.se/˜peppar/docs/rtp srm/ 9 URL:http://www.cdt.luth.se/˜peppar/docs/ 10 URL:http://www.cdt.luth.se/˜peppar/progs/mMOD/
10
>
