B.Tech. Project Report - IIT Kanpur

1 Project ReportA Reliable Multicast Framework forApplicationsRaja MukhopadhyayandVikas GuptaDepartment of Computer Science & EngineeringIndian Institute of TechnologyKanpur, INDIA under the guidance ofDr D. ManjunathandDr Dheeraj SanghiAugust 1995 - April 1996submitted in partial fulfillment ofthe requirements of obtaining the degree ofBachelor of TechnologyinComputer Science & EngineeringCertificateThis is to certify that this Project entitledA Reliable Multicast Frameworkfor Applicationshas been carried out under our supervision and, to the best of ourknowledge, has not been submitted elsewhere as part of the process of obtaining a 9, 1996D. Manjunath Dheeraj SanghiAbstractOur work involves developing a reliable multicast frameworkthat can scale well toboth very large networks and very large sessions. The scalabilityand the efficiency ofthe framework is estimated by using it as the backbone of WhiteBoard , a distributedteleseminaring tool which maintains a shared window supporting graphics and text.

2 Inorder to avoid the associated overhead, the framework does notguarantee that packetswill be delivered in any particular order. Through WhiteBoard , we show how applica-tions can easily extend the framework to enforce any particular order which they mightneed to satisfy their quality of service and foremost, we would like to thank our guides, Dr Manjunath and Dr Sanghi,for having suggested the topic of our Project and for their constant support and guidance,without which we would not have been able to attempt this to Atul Jain and Sandhya Sule for being a constant help throughout theproject. Thanks are also due to Suvrat Gupta for helping out with some of the protocolissues. We thank the Telematics Lab. for providing the necessary hardware and softwarefor developing Whiteboard. We also thank Microsoft Inc. for providing Winsock made our Project possible, and also being one of the most frustrating reasons ofour numerous nights Mukhopadhyay Vikas GuptaContents1 Introduction32 Background and Motivation53 Framework for Building the Skeletal Application.

3 Shifting to Multicast .. 84 Whiteboard Design Providing Concurrency .. Achieving Local Ordering .. Providing Reliability .. User Interface .. 145 Details of The ByteStream Layer .. The Frame Construction Unit .. The Frame Layer .. The Shape Layer .. 166 Conclusions182 Chapter 1 IntroductionWith the emergence of networks providing huge bandwidths and the availability of in-creased processing power at the desktop, multimedia applications no longer remain adistant dream. Of these multimedia applications, perhaps the highest demand is for theconferencing applications which allow a group to coordinate its work on a real-time ba-sis, irrespective of the physical location of the members. Moreover, given the increasingtrend toward distributing work and getting it done on a collaborative basis in industryand elsewhere, the need for such conferencing applications can only rise in the , the technology needed for these conferencing applications is still major reason for this is that multimedia communication has given birth to a host ofnew problems that are still being looked into.

4 Moreover, conferencing applications entaila lot of group dynamics and the traditional method of having point to point connectionsbetween hosts does not scale to these switch to multicast communication - a communication method in which thegroup is treated as an immutable entity with all informationbeing addressed to it ratherthan to the individual members - therefore becomes unavoidable. The problem is thatmost of the methods developed for unicast communication do notcarry over to themulticast unicast communication, the requirements for reliable, sequenced delivery are fairlygeneral. Therefore, it has been possible to come up with schemesthat satisfy these needsfor the whole spectrum of unicast applications. However, different multicast applicationshave have widely varying ordering and reliability requirements. Although generic multi-cast protocols that meet the worst-case requirements, reliability and totalorder, have been reported in the literature, the overhead imposed by these protocols onapplications with more modest requirements is substantial.

5 This precludes the design ofa single multicast delivery scheme that can simultaneously meet the functionality andefficiency requirements of all important thing is to realise is that in the case of multicastcommunication, thebest we can achieve is to have a framework which provides minimal functionality so faras reliability, ordering and latency are concerned. Different applications can then addstructure to this framework to satisfy their quality of service requirements. Our workconcerns the design and development of a multicast framework with the aforementionedproperties. We also use this framework as the backbone for Whiteboard - a multicastapplication providing a shared window which supports the exchange of graphics andtext. We have also looked into the issues involved in providing Whiteboard with audioand video capability so as to have a full-blown multimedia conferencing 2 Background and MotivationTalking of generic reliable multicast protocols, much as TCP is a generic reliable unicasttransport protocol, several approaches have appeared in literature.

6 It has long been rec-ognized that protocols that achieve the reliability, scalability and efficiency requirementsof all applications cannot possibly be designed. An approach forApplication Level Fram-ing (ALF) was proposed by Clark and Tennenhouse [CT90] which explicitly includes theapplication s semantics in the design of that application s protocol. Extensions of ALFinvolved light-weight rendezvous mechanisms based on IP group delivery models, and in-cluded a notion of receiver based adaptation for unreliable,real-time applications, suchas video conferencing. This resulted in development of LightWeight Sessions(LWS),which have been very successful in the development of scalable wide-area suggests that to achieve maximum flexibility, most of the functionality shouldbe left to the application. On these lines, Van Jacobsonet al[JAC95] developed aframework for scalable reliable multicast (SRM).

7 The functionality provided by theirframework is the eventual delivery of all data to all group members, without enforcingany particular order. Their framework has been prototyped in wb , a distributed tele-seminaring application which maintains a shared window supporting graphics and application, which runs under X-Windows, has become popular as whiteboard .Our framework borrows heavily from the SRM framework. Following ALF and SRM,we achieve a framework that achieves eventual delivery of all data to the entire requirements of Whiteboard allowed us to pursue a design devoid of global orderingper se. Since Whiteboard was not destined to be a complete videoconferencing packagein itself, the requirements on ordering and real-time delivery were not very design however still permits an application to use this framework and incorporateits own ordering on the packets exchanged in the group.

8 Thus Whiteboard, while beingable to operate on a stand-alone basis, can be extended to supportmultimedia and5real-time aspects of video of the major motivating factors for Whiteboard was that similar applications donot exist on the most widely used platforms - the PCs. The wb by Van Jacobsonet alprovided the application we were aiming at, but on X-Windows. Our implementationof WhiteBoard is for the MS-Windows platform. We expect a greater reachability anduse of Whiteboard on this platform simply because of its immense presence all over theworld. We eyed Whiteboard as a product that can reach out to a lot of people, and thisencouraged us throughout the 3 Framework for Building the Skeletal ApplicationTo begin with, we have developed a rudimentary whiteboard which supports only graph-ics. To concentrate on the design of the application, rather than on the delivery scheme,we used TCP as the underlying transport communication model comprises a single server and multipleclients.

9 A clientcommunicates with the group by passing the message to the server which then relays it to other members of the group. The packets are sequenced in the order in which theyare received at the server and thus a total order is design is object-oriented and consists of classes like server , client , shape , frame and socket . The shape class is further subdivided into classes like straightline , rectangle , ellipse and curved line . The application is structured in a layeredmanner : the Shape Layer, the Frame Layer and the ByteStream Layer. The ShapeLayer interprets data in terms of shapes and maintains the objects displayed in thewindow. The Frame Layer is concerned with the generation of application protocolframes and communicates with the peer layer to maintain a session. The ByteStreamLayer operates at the socket level and interprets data in terms of bytes.

10 Details on theimplementations are provided in Chapter application level protocol is used by the clients and the server to force a consistentinterpretation of data. To ease the understanding of the protocol, specification of theobject Shape is in order. A Shape can be thought of as an objectwith the attributesType,Identification,Pen Size,ColourandPosition on Screen. The protocol interfaceto the Shape Layer is in terms of objects with the above attributes. Following are thepacket formats used by the CodeObject IdentificationDrawing ModeColouring in RGBPen SizeAbcissa of PointOrdinate of Point08162432 The protocol makes sure that each object drawn on each client window is commu-nicated to all other client windows and is given a unique representation in the a client starts a new object, it sends a request to the server for assigning a newobject id. The server assigns the object a unique identification contained in theObjectIdentificationfield of the frames relayed to all clients regarding the start ofthe , the originator may use this object id to add points to the shape.