g roup c ommunication a pplication level m ulticast
play

G ROUP C OMMUNICATION (A PPLICATION - LEVEL M ULTICAST ) Prasun - PowerPoint PPT Presentation

G ROUP C OMMUNICATION (A PPLICATION - LEVEL M ULTICAST ) Prasun Dewan Department of Computer Science University of North Carolina at Chapel Hill dewan@cs.unc.edu Code available at: https://github.com/pdewan/ColabTeaching P RE -R EQUISITES


  1. G ROUP C OMMUNICATION (A PPLICATION - LEVEL M ULTICAST ) Prasun Dewan Department of Computer Science University of North Carolina at Chapel Hill dewan@cs.unc.edu Code available at: https://github.com/pdewan/ColabTeaching

  2. P RE -R EQUISITES  Model-Interactor Separation  Interaction Types  Model Types 2

  3. F ROM 1- USER TO C OLLABORATIVE Collaboration Functions 3

  4. E CHOER TO IM 4

  5. D ISTRIBUTED D EMOERS public class ALauncherOfIM extends AConsoleModelBasedLauncher implements LauncherOfIM { public Class[] mainClasses() { return new Class[] { sessionManagerClass(), aliceClass(), bobClass(), cathyClass() }; } Can do executeAll or double click on each class in sequence Can simply run each class from programming environment 5

  6. A NATOMY /A RCHITECTURE Interactor/Editor/ View Model Architecture = Program Components = objects? components and their interaction 6

  7. D ISTRIBUTED P ROCESSING Other processes Local Local Local Input Output Output Intercepting Displaying Displaying Process Process Process Output Input Output U1 U2 U3 Direct or indirect distributed comm. 7

  8. V IEWING P ROCESSES A process is created by the Operating System each time a program (in Java a main method) is run Same program may be executed multiple times to create multiple processes 8

  9. P ROCESS VS O BJECT VS D ISTRIBUTED A RCHITECTURE Process architecture describes the processes that implement some Computer 1 Computer 2 potentially distributed application and the Process 1 communication among these Process 3 processes Process 2 Distributed architecture maps processes to computers Object architecture describes the objects and the communication In our demos and among objects in a process testing we will map them all to one 9 machine

  10. S INGLE -U SER  C OLLABORATIVE A RCHITECTURE Replace local calls with Interactor/Editor/ “transparent” remote calls? View Remote calls are not trasparent – must at least deal with communication errors Model Blocking call and round trip delay to get local feedback Central bottleneck which may not always be available Interactor/Editor/ View No awareness of others Sharing at the model level Put the model on one machine and an interactor of a user on Architecture is too constrained! 10 his/her machine

  11. A RBITRARY A RCHITECTURE ? Other processes Local Local Local Input Output Output Intercepting Displaying Displaying Process Process Process Output Input Output U1 U2 U3 Nothing said about other processes and the nature of communication Commonality not exploited 11

  12. A BSTRACTION L AYERS IN C OLLABORATION T OOLKIT ? ??? ??? ??? 12

  13. A BSTRACTION L AYERS IN C OLLABORATION T OOLKIT ? ??? ??? Interprocess Communication (Sockets, RMI, ..) Inter-process communication allows two processes on different hosts to communicate with each other General form: send (host, port, message) 13

  14. P ROCESS VS O BJECT VS D ISTRIBUTED A RCHITECTURE (R EVIEW ) Process architecture describes the processes that implement some Computer 1 Computer 2 potentially distributed application and the Process 1 communication among these Process 3 processes Process 2 Distributed architecture maps processes to computers Object architecture describes the objects and the communication In our demos and among objects in a process testing we will map them all to one 14 machine

  15. A RCHITECTURE VS . D ISTRIBUTED A BSTRACTIONS ??? ??? Interprocess Communication (Sockets, RMI, ..) Inter-process communication allows two processes on different hosts to communicate with each other General form: send (host, port, message) 15

  16. B UILDING IM U SING IPC send(h 1 , p 1 , msg) send(h 3 , p 3 , msg) IPC IPC IPC IM IM IM msg msg msg U 1 U 2 U 3 How did H 2 know about H 1 and H 3 ? Static (hardwired) dynamic “sessions”? 16

  17. D YNAMIC SESSIONS IM Session send(h 1 , p 1 , {h 2 , p 2 }) send(h 2 , p 2 , {h 1 , p 1 }) Manager send(h 1 , p 1 , {u 3 , p 3 }) send(h 2 , p 2 , {h 3 , p 3 }) send(h 3 , p 3 , {h 1 , p 1 }, {h 2 , p 2 }) IPC IPC IPC IM IM IM U 1 U 2 U 3 send(h SM , p SM , h 1 , p 1 ) send(h SM , p SM , h 2 , p 2 ) send(h SM , p SM , h 3 , p 3 ) 17

  18. D YNAMIC P2P IM Session Manager IPC IPC IPC send(h 1 , p 1 , msg) send(h 3 , p 3 , msg) IM IM IM msg msg msg U 1 U 2 U 3 18

  19. D YNAMIC S ESSIONS (R ELAYED ) Why IM indirection? Session Manager IPC IPC IPC send(h SM , p SM , msg) IM IM IM msg msg msg U 1 U 2 U 3 Many reasons for using relayed (consistency, security, performance) 19 Higher-level abstraction than IPC?

  20. A BSTRACTION L AYERS IN C OLLABORATION T OOLKIT ? ??? Group Communication (Multicast) Interprocess Communication (Sockets, RMI, ..) 20

  21. A PP -S PECIFIC S ESSION M ANAGER IM Session send(h 1 , p 1 , {h 2 , p 2 }) send(h 2 , p 2 , {h 1 , p 1 }) Manager send(h 1 , p 1 , {h 3 , p 3 }) send(h 2 , p 2 , {h 3 , p 3 }) send(h 3 , p 3 , {h 1 , p 1 }, {h 2 , p 2 }) IPC IPC IPC IM IM IM U 1 U 2 U 3 send(h SM , p SM , h 1 , p 1 ) send(h SM , p SM , h 2 , p 2 ) send(h SM , p SM , h 3 , p 3 ) 21

  22. A PP -S PECIFIC S ESSION M ANAGER (N O C ALLBACKS ) IM Session Manager IPC IPC IPC IM IM IM U 1 U 2 U 3 send(h SM , p SM , h 1 , p 1 ) send(h SM , p SM , h 2 , p 2 ) send(h SM , p SM , h 3 , p 3 ) 22

  23. G ENERIC S ESSION M ANAGER (O NE PER C OLLABORATIVE “S ESSION ” ) Generic Session Manager IPC IPC IPC IM IM IM U 1 U 2 U 3 send(h SM , p SM , h 1 , p 1 ) send(h SM , p SM , h 2 , p 2 ) send(h SM , p SM , h 3 , p 3 ) 23 Should clients have to know about ports or send its host?

  24. G ENERIC S ESSION M ANAGER (C LIENT L IBRARY , O NE PER C OLLABORATIVE S ESSION ) As before session manager Generic Library will have to be told can send host and port Session about session manager host number to applicatiom Manager for this application send(h 3 , p 3 , {h 1 , p 1 }, {h 2 , p 2 }) Group Group Group Local library at Comm. Comm. Comm. each site IM IM IM U 1 U 2 U 3 join(h SM ) join(h SM ) join(h SM ) IPC send replaced by Library could fill in port a la Web browser and can 24 group comm. join also register own port and send its host

  25. D YNAMIC P2P, N O M ULTICAST Generic Better Session communication Manager support? Group Group Group Comm. Comm. Comm. send(h 1 , p 1 , msg) send(h 3 , p 3 , msg) IM IM IM msg msg msg U 1 U 2 U 3 25

  26. D YNAMIC P2P A PPLICATION -L EVEL M ULTICAST Single message delivered to Generic network layer which can result Application-level multicast: Session in a single message being put Multiple messages delivered to Manager on the wire for multiple network layer destinations Group Group Group Comm. Comm. Comm. toOthers(msg) IM IM IM msg msg msg U 1 U 2 U 3 Application code does not have to define Application code can be unaware of a session participant callback and specific users 26 maintain information about participants

  27. D YNAMIC S ESSIONS (R ELAYED ) Generic Session Manager Group Group Group Comm. Comm. Comm. toOthers(msg) IM IM IM msg msg msg U 1 U 2 U 3 27

  28. F LEXIBLE G ROUP C OMMUNICATION Same logical call made Generic in both relayed and p2p Session case Manager Group Group Group Comm. Comm. Comm. toOthers(msg) IM IM IM msg msg msg U 1 U 2 U 3 It can choose based on security and performance Library can support both It can let application characteristics (but not 28 forms of communication choose consistency)

  29. S PECIFYING R OUTE AT J OIN T IME : P2P Generic Session Manager Group Group Group Comm. Comm. Comm. toOthers(msg) IM IM IM msg msg msg U 1 U 2 U 3 join(h SM , Direct) Each site chooses Sent Directly 29 independently

  30. S PECIFYING R OUTE AT J OIN T IME : R ELAYED Generic Session Manager Group Group Group Comm. Comm. Comm. toOthers(msg) IM IM IM msg msg msg U 1 U 2 U 3 join(h SM , Relayed) Relayed communication 30

  31. A DDITIONAL M ULTICAST G ROUPS ? All session members other Generic than the caller Session Manager Group Group Group Comm. Comm. Comm. toOthers(msg) IM IM IM msg msg msg U 1 U 2 U 3 31

  32. TO A LL All session members including Generic the caller Session Manager Group Group Group Comm. Comm. Comm. toAll(msg) IM IM IM msg msg msg U 1 U 2 U 3 32

  33. MUD (M ULTI -U SER D UNGEONS ): O THER G ROUPS  say | " your utterance here toOthers(msg) Everyone in the room can 'hear' what you 'say', or see what you type.  w hisper playername = your whisper here ... so only the player(s) named, and in the room, can hear your whisper. toClient(user, msg)  mut ter player = message Mutters message to everyone in the same room EXCEPT player . toClients({u 1 , .., u n }, msg) join(h SM , u 2, Relayed) User-aware application code but not host and Logical user id (credentials) rather than port aware physical host given as argument 33 Curtis, P. (1992), Muddings: Social Phenomena in Text-Based Virtual Reality . 1992: Xerox Palo Alto Research Center.

  34. S INGLE S ESSION PER S ESSION M ANAGER Generic Multiple sessions? Session Manager Group Group Group Comm. Comm. Comm. toOthers(msg) IM IM IM msg msg msg U 1 U 2 U 3 join(h SM , u 2 , Relayed) 34

  35. S INGLE S ESSION P ER S ESSION M ANAGER IM IM Generic Generic Session Session Manager Manager IM IM IM 35

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend