1. Kyung Hee University 1/57 Communication Chapter 3

2. Kyung Hee University 2/57 Agenda 1-Threads (N.Q.Hung) (N.Q.Hung) 2-Clients (L.X.Hung) (L.X.Hung) 3-Servers (L.X.Hung) (L.X.Hung) 4-Code Migration (N.Q.Hung) (N.Q.Hung) 5-Software Agent (L.X.Hung) (L.X.Hung)

3. Kyung Hee University 3/57 Chapter 3 Process Part 1 THREAD

4. Kyung Hee University 4/57 Process at a glance

5. Kyung Hee University 5/57 Process Process Control Block (PCB)

6. Kyung Hee University 6/57

7. Kyung Hee University 7/57 Thread

8. Kyung Hee University 8/57

9. Kyung Hee University 9/57

10. Kyung Hee University 10/57 Kernel-Level Threads Kernel is aware of and schedules threads A blocking system call, will not block all peer threads Expensive to manage threads Expensive context switch Kernel Intervention Maybe as expensive as using processes!!

11. Kyung Hee University 11/57 Light-Weight Processes (LWP) Support for hybrid (user-level and Kernel) threads A process contains several LWPs Developer: creates multi-threaded applications System: Maps threads to LWPs for execution

12. Kyung Hee University 12/57 Thread Implementation-LWP (1) Combining kernel-level lightweight processes and user-level threads.

13. Kyung Hee University 13/57 Thread Implementation - LWP (2) Each LWP offers a virtual CPU LWPs are created by system calls They all run the scheduler, to schedule a thread Thread table is kept in user space Thread table is shard by all LWPs LWPs switch context between threads

14. Kyung Hee University 14/57 Thread Implementation - LWP (3) When a thread blocks, LWP schedules another ready thread Thread context switch is completely done in user-address space When a thread blocks on a system call,execution mode changes from user to kernel but continues in the context of the current LWP When current LWP can no longer execute, context is switched to another LWP

15. Kyung Hee University 15/57 LWP Advantages Cheap thread management A blocking system call may not suspend the whole process LWPs are transparent to the application LWPs can be easily mapped to different CPUs Managing LWPs is expensive (like kernel threads)

16. Kyung Hee University 16/57 Threads and Distributed Systems Important property of thread: a blocking system call will not block the entire process Very attractive to maintain multiple logical connections between many clients and a server

17. Kyung Hee University 17/57 Multi-Threaded Clients High propagation delay in big networks WAN: a round trip delay ~ seconds To hide this delay, use threads Initiate communication by a separate thread Example: Web browsers Separate connection for each page component (HTML file, image, audio…) Better: if server is horizontally distributed, data will be transferred in parallel

18. Kyung Hee University 18/57 Multi-Threaded Servers (1) Much more Important than multi-threaded clients Not only simplifies server code, but also boosts server performance (exploit parallelism) It is common to have multiple-CPU (Multiprocessor) server machines Example: File Server (fig)

19. Kyung Hee University 19/57 Multithreaded Servers (2) A multithreaded server organized in a dispatcher/worker model.

20. Kyung Hee University 20/57 Multithreaded Servers (3) Three ways to construct a server. ModelCharacteristics ThreadsParallelism, blocking system calls Single-threaded processNo parallelism, blocking system calls Finite-state machineParallelism, nonblocking system calls Back to Agenda

21. Kyung Hee University 21/57 Clients and Servers

22. Kyung Hee University 22/57 Clients Main role of clients is: to interact with human user and remote server -User Interface (UI): -Client-side software: UI + components for achieving transparent

23. Kyung Hee University 23/57 User Interface The X-Window System Goal Generally is used to control bit-mapped terminals (include a monitor, keyboard, mouse) (or a part of OS that controls the terminal) X-kernel: -Contains all terminal-specific devices -Offer relative low-level interface for controlling the screen -Capturing evens from the keyboard and mouse Comprise 4 major components: -X Servers: Managing the screen, mouse and keyboard -> interact with the user -X Clients: The application (where the real work gets done ) -X Protocol: Client/server communication -X Library: The Programming interface

24. Kyung Hee University 24/57 User Interface The basic organization of the X Window System The X-Window System

25. Kyung Hee University 25/57 Client-Side Software for Distribution Transparency -UI is a small part of the client-side S/W -Client S/W includes: +Local processing +Communication facilities: distribution transparency +Replication transparency (next slide) +Access transparency: client stub +Location, migration, relocation transparency: naming +Failure transparency

26. Kyung Hee University 26/57 Client-Side Software for Distribution Transparency A possible approach to transparent replication of a remote object using a client-side solution. Common interface to Service Client or Server side

27. Kyung Hee University 27/57 Servers

28. Kyung Hee University 28/57 Servers: General Design Issues 1-Organize of server? 2-How client contacts with server? 3-Whether and how a server can be interrupt? 4-Stateful or Stateless server?

29. Kyung Hee University 29/57 Servers: General Design Issues 1-Organize of server? -Iterative server (sequential server): itself handle the request and return a response to the request. -Concurrent server: does not handle the request but passes it into threads (Ex multithreads server)

30. Kyung Hee University 30/57 Servers: General Design Issues 2-How client contacts with server? Way: Clients send the request to the endpoint (port) of the server Approach 1: Endpoint is assigned with the well-know service (Ex: FPT request listen to port 21, HTTP: port 80) Approach 2 : Not preassigned endpoint (next slice) Solution 1: Each server has a special daemon to keep tracks of the current endpoint of each service (Ex: DCE) Solution 2:Using a single SuperServer (inetd in UNIX)

31. Kyung Hee University 31/57 Servers: General Design Issues a)Client-to-server binding using a daemon as in DCE b)Client-to-server binding using a superserver as in UNIX 3.7

32. Kyung Hee University 32/57 Servers: General Design Issues 3- Whether and how a server can be interrupt? Approach 1: Client suddenly exits the application and restarts it immediately  server thinks the client had crashed and will tear down the connection. Approach 2 (better): Send out-of-band data (which is process by the server before any other client data) -Solution 1: Out-of-band data is listened by separated endpoint. -Solution 2: Out-of-band data is sent across the same connection with urgent

33. Kyung Hee University 33/57 Servers: General Design Issues 4- Stateful or Stateless server? Stateless server: -Does not keep information on the state of its clients. -Can change it own state without having to inform any client. Ex: Web server Stateful server: - Does maintain information on its clients. Ex: File server

34. Kyung Hee University 34/57 Object Servers - Tailored for distributed objects support -Provides environment for objects -Not a service by itself (government) -Services are provided by objects -Easy to add services (by adding Objects) Object Data Code (methods) Object server Object

35. Kyung Hee University 35/57 Invoking Objects The Object Server is needed to know: -Which code is execute? -On which data is should operate?

36. Kyung Hee University 36/57 Invoking Objects Activation Policies Decisions on how to invoke objects All objects are alike –Inflexible Objects differ and require different policies –Object type –Memory allocation –Threading

37. Kyung Hee University 37/57 Create at the first invocation request and destroy when clients are no longer bound to it Create all transient objects when server is initialized Server resources? Invocation time? Transient Objects

38. Kyung Hee University 38/57 Each object has its own memory segment Objects can share memory segments Security? Memory resources? Memory Allocation

39. Kyung Hee University 39/57 One thread in the server Several threads in the server Separate thread for each object Separate thread for each request Concurrent access? Threads

40. Kyung Hee University 40/57 A S/W implementation of an activation policy Generic to support developers Group objects per policy Several objects under an adapter Several adapters under a server Object Adapters (Wrappers)

41. Kyung Hee University 41/57 Organization of an object server supporting different activation policies. Object Adapters (Wrappers) Back to agenda

42. Kyung Hee University 42/57 Chapter 3 Process Part 4. Code migration

43. Kyung Hee University 43/57 Code Migration Code Migration = moving processes between machines Process = 3 segments Text segment (the code) Resource segment (refs to external resources {files, printers, devices, other processes, etc}) Execution segment (state of a process {stack, program counter, registers, private data …} )

44. Kyung Hee University 44/57 Why migrate code? (1) Main Reason: Better performance of overall system

45. Kyung Hee University 45/57 Why migrate code? (2)  Load-Balancing (for multiprocessors) Move process from over-utilized to under-utilized CPU  Minimizing Communication Costs  Exploiting parallelism Examples: client application needs to do many database operations involving large quantities of data => ship part of the client application to the server Interactive database applications: client needs to fill in forms => ship part of the server application to the client Searching information in the Web by a small mobile prog. => send some copies of such a prog. off to different sites

46. Kyung Hee University 46/57 Why migrate code? (3)  Besides improving performance: Flexibility  Clients need not have all the S/W pre-installed: download on demand, then dispose. Remote object stub in Java Java applets  Security: Can you trust any code? (both client & server)  Need a standardized protocol for downloading & initializing code  Guarantee that downloaded code can be executed

47. Kyung Hee University 47/57 Scenario of Migrating Code The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server.

48. Kyung Hee University 48/57 Models for Code Migration Alternatives for code migration. Transfer only the code segment => simplicity Execution segment can be transferred as well (running process can be stopped & moved to another machine to resume execution) anonymous Require registration & authentication at the server Eg: search prog., uploading programs to a compute server Process = 3 segments Text segment (the code) Resource segment (refs to external resources {files, printers, devices, other processes, etc}) Execution segment (state of a process {stack, program counter, registers, private data …} )

49. Kyung Hee University 49/57 GR: Establish a global systemwide reference MV: Move the Resource CP: Copy the value of the resource RB: Rebind process to locally available resource Migration and Local Resources Actions to be taken with respect to the references to local resources when migrating code to another machine. UnattachedFastenedFixed By identifier By value By type MV (or GR) CP ( or MV, GR) RB (or GR, CP) GR (or MV) GR (or CP) RB (or GR, CP) GR RB (or GR) Resource-to machine binding Process-to- resource binding Binding by identifier: e.g, uses a URL for Website or IP address for FTP server. Binding by value: e.g, C or Java standard libraries Binding by type: local devices such as monitors, printers, … Unattached resources: can easily moved between different machines, typically (data) files associated only with the program that is to be migrated. Fastened resources: eg, local databases, complete Websites (moveable but high costs) Fixed resources: local devices

50. Kyung Hee University 50/57 Migration in Heterogeneous Systems  Requirements:  Platform supported: code segment may be recompiled to be executed in new platform  Ensure the execution segment can be represented at each platform properly.  Solutions:  Weak mobility: no runtime information needs to be transferred => just recompile the source code  Strong mobility: segment is highly dependent on the plaform => migration stack: a copy of the program stack in a machine-independent way.(C, Java)  Scenario:  Migration can take place only when a next subroutine is called.  When subroutine is called: marshalled data are pushed onto the migration stack along with identifier for the called subroutine & the return label  Then all global program-specific data are also marshalled (current stack & machine-specific data are ignored)

51. Kyung Hee University 51/57 Migration in Heterogeneous Systems The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment 3-15 end

52. Kyung Hee University 52/57 Software Agents

53. Kyung Hee University 53/57 Software Agents Definition: Is as an autonomous process capable of reacting to, and changes in, its environment, possibly in collaboration with users and other agents

54. Kyung Hee University 54/57 Software Agents in Distributed Systems Some important properties by which different types of agents can be distinguished. Property Common to all agents? Description AutonomousYesCan act on its own ReactiveYesResponds timely to changes in its environment ProactiveYesInitiates actions that affects its environment CommunicativeYes Can exchange information with users and other agents ContinuousNoHas a relatively long lifespan MobileNoCan migrate from one site to another AdaptiveNoCapable of learning

55. Kyung Hee University 55/57 Agent Technology The general model of an agent platform (adapted from [fipa98-mgt]).

56. Kyung Hee University 56/57 Agent Communication Languages (1) Components of a message

57. Kyung Hee University 57/57 Agent Communication Languages (1) Examples of different message types in the FIPA ACL [fipa98-acl], giving the purpose of a message, along with the description of the actual message content. Message purposeDescriptionMessage Content INFORMInform that a given proposition is trueProposition QUERY-IFQuery whether a given proposition is trueProposition QUERY-REFQuery for a give objectExpression CFPAsk for a proposalProposal specifics PROPOSEProvide a proposalProposal ACCEPT-PROPOSALTell that a given proposal is acceptedProposal ID REJECT-PROPOSALTell that a given proposal is rejectedProposal ID REQUESTRequest that an action be performedAction specification SUBSCRIBESubscribe to an information source Reference to source

58. Kyung Hee University 58/57 Agent Communication Languages (2) A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information. FieldValue PurposeINFORM Sendermax@http://fanclub-beatrix.royalty-spotters.nl:7239 Receiverelke@iiop://royalty-watcher.uk:5623 LanguageProlog Ontologygenealogy Contentfemale(beatrix),parent(beatrix,juliana,bernhard)

59. Kyung Hee University 59/57 End of chapter 3 Thank you for joining us!