kyung hee university 1/57 communication chapter 3

1/57

Kyung Hee University

Communication

Chapter 3

2/57


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/57


Chapter 3 Process

Part 1 THREAD

4/57


Process at a glance

5/57


Process

Process Control Block (PCB)

6/57


7/57


Thread

8/57


9/57


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/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/57


Thread Implementation-LWP (1)

Combining kernel-level lightweight processes and user-level threads.

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/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/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/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/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/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/57


Multithreaded Servers (2)

A multithreaded server organized in a dispatcher/worker model.

20/57


Multithreaded Servers (3)

Three ways to construct a server.

Model Characteristics

Threads Parallelism, blocking system calls

Single-threaded process No parallelism, blocking system calls

Finite-state machine Parallelism, nonblocking system calls

Back to Agenda

21/57


Clients and Servers

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/57


User InterfaceThe X-Window SystemGoalGenerally 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/57


User Interface

The basic organization of the X Window System

The X-Window System

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/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 orServer side

27/57


Servers

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/57


Servers: General Design Issues1-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/57


Servers: General Design Issues2-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/57


Servers: General Design Issues

a) Client-to-server binding using a daemon as in DCEb) Client-to-server binding using a superserver as in UNIX

3.7

32/57


Servers: General Design Issues3- 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/57


Servers: General Design Issues4- 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/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 Object

Object

35/57


Invoking Objects

The Object Server is needed to know:-Which code is execute?

-On which data is should operate?

36/57


Invoking ObjectsActivation Policies• Decisions on how to invoke objects• All objects are alike

– Inflexible

• Objects differ and require different policies– Object type– Memory allocation– Threading

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/57


• Each object has its own memory segment

• Objects can share memory segments

• Security?

• Memory resources?

Memory Allocation

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/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/57


Organization of an object server supporting different activation policies.

Object Adapters (Wrappers)

Back to agenda

42/57


Chapter 3 Process

Part 4. Code migration

43/57


Code Migration

• Code Migration = moving processes between machines

• Process = 3 segmentsText 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/57


Why migrate code? (1)

Main Reason: Better performance of

overall system

45/57


Why migrate code? (2)Load-Balancing (for multiprocessors)

Move process from over-utilized to under-utilized CPU

Minimizing Communication CostsExploiting 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/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/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/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 serverEg: 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/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.

Unattached Fastened Fixed

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

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 librariesBinding 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/57


Migration in Heterogeneous SystemsRequirements:

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/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/57


Software Agents

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/57


Software Agents in Distributed Systems

Some important properties by which different types of agents can be distinguished.

PropertyCommon to all agents?

Description

Autonomous Yes Can act on its own

Reactive Yes Responds timely to changes in its environment

Proactive Yes Initiates actions that affects its environment

Communicative YesCan exchange information with users and other agents

Continuous No Has a relatively long lifespan

Mobile No Can migrate from one site to another

Adaptive No Capable of learning

55/57


Agent Technology

The general model of an agent platform (adapted from [fipa98-mgt]).

56/57


Agent Communication Languages (1)

Components of a message

57/57



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 purpose Description Message Content

INFORM Inform that a given proposition is true Proposition

QUERY-IF Query whether a given proposition is true Proposition

QUERY-REF Query for a give object Expression

CFP Ask for a proposal Proposal specifics

PROPOSE Provide a proposal Proposal

ACCEPT-PROPOSAL Tell that a given proposal is accepted Proposal ID

REJECT-PROPOSAL Tell that a given proposal is rejected Proposal ID

REQUEST Request that an action be performed Action specification

SUBSCRIBE Subscribe to an information sourceReference to source

58/57



A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information.

Field Value

Purpose INFORM

Sender max@http://fanclub-beatrix.royalty-spotters.nl:7239

Receiver elke@iiop://royalty-watcher.uk:5623

Language Prolog

Ontology genealogy

Content female(beatrix),parent(beatrix,juliana,bernhard)

59/57


End of chapter 3

Thank you for joining us!

kyung hee university 1/57 communication chapter 3

Documents