Communication

1. Communication Chapter 3

2. Agenda • 1-Threads (N.Q.Hung) • 2-Clients (L.X.Hung) • 3-Servers (L.X.Hung) • 4-Code Migration (N.Q.Hung) • 5-Software Agent (L.X.Hung)

3. Chapter 3 ProcessPart 1 THREAD

4. Process at a glance

5. Process • Process Control Block (PCB)

7. Thread

10. 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. 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. Thread Implementation-LWP (1) • Combining kernel-level lightweight processes and user-level threads.

13. 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. 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. 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. 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. 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. 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. Multithreaded Servers (2) • A multithreaded server organized in a dispatcher/worker model.

20. Multithreaded Servers (3) • Three ways to construct a server. Back to Agenda

21. Clients and Servers

22. 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. 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. User Interface The X-Window System • The basic organization of the X Window System

25. 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. Common interface to Service Client or Server side Client-Side Software for Distribution Transparency • A possible approach to transparent replication of a remote object using a client-side solution.

27. Servers

28. 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. 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. 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. Servers: General Design Issues 3.7 • Client-to-server binding using a daemon as in DCE • Client-to-server binding using a superserver as in UNIX

32. 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) -Solution1: Out-of-band data is listened by separated endpoint. -Solution 2: Out-of-band data is sent across the same connection with urgent

33. 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. 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 server Object Object Object Code (methods) Data Object

35. Invoking Objects • The Object Server is needed to know: • -Which code is execute? • -On which data is should operate?

36. 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. Transient Objects • 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?

38. Memory Allocation • Each object has its own memory segment • Objects can share memory segments • Security? • Memory resources?

39. Threads • One thread in the server • Several threads in the server • Separate thread for each object • Separate thread for each request • Concurrent access?

40. Object Adapters (Wrappers) • 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

41. Object Adapters (Wrappers) • Organization of an object server supporting different activation policies. Back to agenda

42. Chapter 3 ProcessPart 4. Code migration

43. 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. Why migrate code? (1) • Main Reason: • Better performance of overall system

45. 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. 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. 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. Models for Code Migration Require registration & authentication at the server Eg: search prog., uploading programs to a compute server Transfer only the code segment => simplicity • 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…}) anonymous Execution segment can be transferred as well (running process can be stopped & moved to another machine to resume execution) • Alternatives for code migration.

49. Migration and Local Resources 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, … Resource-to machine binding Process-to-resource binding GR: Establish a global systemwide reference MV: Move the Resource CP: Copy the value of the resource RB: Rebind process to locally available resource 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 • Actions to be taken with respect to the references to local resources when migrating code to another machine.

50. Migration in Heterogeneous Systems • 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) • 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.