Ipc Inter process communicatiom, Exams of Distributed Programming and Computing

Inter process communicatiom (Ipc)

Typology: Exams

2015/2016

Uploaded on 01/23/2016

Pramod.Gautam
Pramod.Gautam 🇳🇵

1 document

1 / 8

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Inter-process communication
An example showing a grid computing system connecting many personal computers over the internet using inter-
process network communication.
In computer science, inter-process communication (IPC) is the activity of sharing data across multiple and
commonly specialized processes using communication protocols. Typically, applications using IPC are categorized
as clients and servers, where the client requests data and the server responds to client requests. Many applications
are both clients and servers, as commonly seen in distributed computing. Methods for achieving IPC are divided
into categories which vary based on software requirements, such as performance and modularity requirements, and
system circumstances, such as network bandwidth and latency.
There are several reasons for implementing inter-process communication systems:
Sharing information; for example, web servers use IPC to share web documents and media with users through a web
browser.
Distributing labor across systems; for example, Wikipedia uses multiple servers that communicate with one another
using IPC to process user requests.
Privilege separation; for example, HMI software systems are separated into layers based on privileges to minimize
the risk of attacks. These layers communicate with one another using encrypted IPC.
The Windows operating system provides mechanisms for facilitating communications and data sharing between
applications. Collectively, the activities enabled by these mechanisms are called interprocess
communications (IPC). Some forms of IPC facilitate the division of labor among several specialized processes.
Other forms of IPC facilitate the division of labor among computers on a network.
Typically, applications can use IPC categorized as clients or servers. A client is an application or a process that
requests a service from some other application or process. A server is an application or a process that responds to
a client request. Many applications act as both a client and a server, depending on the situation. For example, a word
processing application might act as a client in requesting a summary table of manufacturing costs from a
spreadsheet application acting as a server. The spreadsheet application, in turn, might act as a client in requesting the
latest inventory levels from an automated inventory control application.
After you decide that your application would benefit from IPC, you must decide which of the available IPC methods
to use. It is likely that an application will use several IPC mechanisms. The answers to these questions determine
whether an application can benefit by using one or more IPC mechanisms.
Should the application be able to communicate with other applications running on other computers on a network, or
is it sufficient for the application to communicate only with applications on the local computer?
Should the application be able to communicate with applications running on other computers that may be running
under different operating systems (such as 16-bit Windows or UNIX)?
Should the user of the application have to choose the other applications with which the application communicates,
or can the application implicitly find its cooperating partners?
Should the application communicate with many different applications in a general way, such as allowing cut-and-
paste operations with any other application, or should its communications requirements be limited to a restricted set
of interactions with specific other applications?
Is performance a critical aspect of the application? All IPC mechanisms include some amount of overhead.
Should the application be a GUI application or a console application? Some IPC mechanisms require a GUI
application.
The following IPC mechanisms are supported by Windows:
Clipboard
COM
Data Copy
pf3
pf4
pf5
pf8

Partial preview of the text

Download Ipc Inter process communicatiom and more Exams Distributed Programming and Computing in PDF only on Docsity!

Inter-process communication

An example showing a grid computing system connecting many personal computers over the internet using inter- process network communication. In computer science, inter-process communication ( IPC ) is the activity of sharing data across multiple and commonly specialized processes using communication protocols. Typically, applications using IPC are categorized as clients and servers , where the client requests data and the server responds to client requests. Many applications are both clients and servers, as commonly seen in distributed computing. Methods for achieving IPC are divided into categories which vary based on software requirements, such as performance and modularity requirements, and system circumstances, such as network bandwidth and latency. There are several reasons for implementing inter-process communication systems: Sharing information; for example, web servers use IPC to share web documents and media with users through a web browser. Distributing labor across systems; for example, Wikipedia uses multiple servers that communicate with one another using IPC to process user requests. Privilege separation; for example, HMI software systems are separated into layers based on privileges to minimize the risk of attacks. These layers communicate with one another using encrypted IPC.

The Windows operating system provides mechanisms for facilitating communications and data sharing between applications. Collectively, the activities enabled by these mechanisms are called interprocess communications (IPC). Some forms of IPC facilitate the division of labor among several specialized processes. Other forms of IPC facilitate the division of labor among computers on a network. Typically, applications can use IPC categorized as clients or servers. A client is an application or a process that requests a service from some other application or process. A server is an application or a process that responds to a client request. Many applications act as both a client and a server, depending on the situation. For example, a word processing application might act as a client in requesting a summary table of manufacturing costs from a spreadsheet application acting as a server. The spreadsheet application, in turn, might act as a client in requesting the latest inventory levels from an automated inventory control application. After you decide that your application would benefit from IPC, you must decide which of the available IPC methods to use. It is likely that an application will use several IPC mechanisms. The answers to these questions determine whether an application can benefit by using one or more IPC mechanisms. Should the application be able to communicate with other applications running on other computers on a network, or is it sufficient for the application to communicate only with applications on the local computer? Should the application be able to communicate with applications running on other computers that may be running under different operating systems (such as 16-bit Windows or UNIX)? Should the user of the application have to choose the other applications with which the application communicates, or can the application implicitly find its cooperating partners? Should the application communicate with many different applications in a general way, such as allowing cut-and- paste operations with any other application, or should its communications requirements be limited to a restricted set of interactions with specific other applications? Is performance a critical aspect of the application? All IPC mechanisms include some amount of overhead. Should the application be a GUI application or a console application? Some IPC mechanisms require a GUI application. The following IPC mechanisms are supported by Windows: Clipboard COM Data Copy

DDE

File Mapping Mailslots Pipes RPC Windows Sockets Using the Clipboard for IPC The clipboard acts as a central depository for data sharing among applications. When a user performs a cut or copy operation in an application, the application puts the selected data on the clipboard in one or more standard or application-defined formats. Any other application can then retrieve the data from the clipboard, choosing from the available formats that it understands. The clipboard is a very loosely coupled exchange medium, where applications need only agree on the data format. The applications can reside on the same computer or on different computers on a network.

Key Point: All applications should support the clipboard for those data formats that they understand. For example, a text editor or word processor should at least be able to produce and accept clipboard data in pure text format.

Using COM for IPC Applications that use OLE ( Object Linking and Embedding is a proprietary technology developed by Microsoft that allows embedding and linking to documents and other objects.) manage compound documents —that is, documents made up of data from a variety of different applications. OLE provides services that make it easy for applications to call on other applications for data editing. For example, a word processor that uses OLE could embed a graph from a spreadsheet. The user could start the spreadsheet automatically from within the word processor by choosing the embedded chart for editing. OLE takes care of starting the spreadsheet and presenting the graph for editing. When the user quit the spreadsheet, the graph would be updated in the original word processor document. The spreadsheet appears to be an extension of the word processor.

The foundation of OLE is the Component Object Model (COM). A software component that uses COM can communicate with a wide variety of other components, even those that have not yet been written. The components interact as objects and clients. Distributed COM extends the COM programming model so that it works across a network.

Key Point: OLE supports compound documents and enables an application to include embedded or linked data that, when chosen, automatically starts another application for data editing. This enables the application to be extended by any other application that uses OLE. COM objects provide access to an object's data through one or more sets of related functions, known as interfaces.

Using Data Copy for IPC Data copy enables an application to send information to another application using the WM_COPYDATA message. This method requires cooperation between the sending application and the receiving application. The receiving application must know the format of the information and be able to identify the sender. The sending application cannot modify the memory referenced by any pointers.

Key Point: Data copy can be used to quickly send information to another application using Windows messaging.

Using DDE for IPC DDE ( Dynamic Data Exchange allows one program to subscribe to items made available by another program, for example a cell in a Microsoft Excel spreadsheet, and be notified whenever a change of that item occurs. DDE was partially superseded by Object Linking and Embedding (OLE), but remains used for simple interprocess communication tasks.) is a protocol that enables applications to exchange data in a variety of formats. Applications can use DDE for one-time data exchanges or for ongoing exchanges in which the applications update one another as new data becomes available. The data formats used by DDE are the same as those used by the clipboard. DDE can be thought of as an extension of the clipboard mechanism. The clipboard is almost always used for a one-time response to a user command, such as choosing the Paste command from a menu. DDE is also usually initiated by a user command, but it often

RPC enables applications to call functions remotely. Therefore, RPC makes IPC as easy as calling a function. RPC operates between processes on a single computer or on different computers on a network. The RPC provided by Windows is compliant with the Open Software Foundation (OSF) Distributed Computing Environment (DCE). This means that applications that use RPC are able to communicate with applications running with other operating systems that support DCE. RPC automatically supports data conversion to account for different hardware architectures and for byte-ordering between dissimilar environments. RPC clients and servers are tightly coupled but still maintain high performance. The system makes extensive use of RPC to facilitate a client/server relationship between different parts of the operating system.

Key Point: RPC is a function-level interface, with support for automatic data conversion and for communications with other operating systems. Using RPC, you can create high-performance, tightly coupled distributed applications.

Using Windows Sockets for IPC Windows Sockets is a protocol-independent interface. It takes advantage of the communication capabilities of the underlying protocols. In Windows Sockets 2, a socket handle can optionally be used as a file handle with the standard file I/O functions. Windows Sockets are based on the sockets first popularized by Berkeley Software Distribution (BSD). An application that uses Windows Sockets can communicate with other socket implementation on other types of systems. However, not all transport service providers support all available options.

Key Point: Windows Sockets is a protocol-independent interface capable of supporting current and emerging networking capabilities.

Group Communications

Group communication: one source process sending a message to a group of processes: Destination is a group rather than a single process. — Broadcast – destination is everybody. — Multicast – destination is a designated group. — Unicast – destination is a single process. Useful: for many applications, the recipient of a message is a group of related process. Many services in DS are implemented by a group of processes, possibly distributed in multiple machines.

Examples of use:

(a) Fault tolerance based on replicated servers: The service is implemented by a group of (replicated) server processes. A client process multicast(Send-to-group) request message to the server group. Each group member performs identical operation on a request.

(b) Locating objects in distributed service: For example, a distributed file service is implemented by a group of servers. The files are not replicated. A client looking for a particular file multicast the request message to the server group. The member holding the wanted file responds_._

(c) Updating replicated data: Data may be replicated to improve performance (response time) and reliability. The data is replicated on multiple servers which forms a server group. Update requests are multicasts to the group.

(d) Multiple notification: For example, a group of processes need be notified of certain event. When the event occurs, a message can be multicasted to the group. A specific example is in the multicasting of flight information to a group of display processes in an airport terminal system. A Group is a collection of processes: G = { P (^) 1 , P 2 , …, P (^) n }

Group management functions:

Forming a group: Create-group ( out gid: group-id) returns a group identifier Joining a Group: Join-group ( in gid: group-id) makes the caller process a member of the group gid. Leaving a group: Leave-group ( in gid: group-id) remove the caller process from the group. Delete a group: Delete-group ( in gid: group-id) Only authorized process (such as the creator) can delete a group.

  • Dynamic group vs static group

Closed Group: Processes outside the group cannot multicast to the group, although an outsider process can send to individual member of the group.

Implementations (of group): Centralised: Use a group management server.

  • All group membership function requests are handled by the server.
  • Server keeps database of all active groups (membership) in the system.
  • Pro: implementation ease. Con: server may be reliability and performance bottleneck. Distributed: Each group member keeps track of membership. Membership function requests are multicast to all members.
  • Pro: reliable
  • Cons: complexity and overheads

Not adequate for some application. e.g., two client processes P (^) 1 and P 2 are multicasting update requests to a server group whose member are holding replicated data. Suppose P (^) 1 sends M 1 , then M 2 ; and at about the same time P (^) 2

sends N (^) 1 then N 2. Further suppose the group consists of 2 server processes S (^) 1 and S (^) 2. The message can arrive at the following order and still satisfy FIFO order: at S (^) 1 : M 1 -> N 1 -> M 2 -> N 2 at S (^) 2 : N 1 -> M 1 -> M 2 -> N 2 The above order may lead to inconsistent result.

  • Consistent order The relative order of messages received at each member process is the same. That is, the order is consistent across the group.
  • Causal order Assume S (^) 1 first multicasts m , upon reception of m , S (^) 3 multicasts m’ , then m -> m’. m and m’ are said to be causally ordered. Causal order could be violated. e.g., due to network delay. A group communication mechanism is said to observe casual order if it preserves the order.

Total order When a group communication mechanism satisfies both causal order and consistent order, we say the mechanism satisfies total order. That is, The message order at each member process preserves causal order and that the message ordering is the same across the entire group.

Implementation: Use a logical clock global to the distributed system to timestamp messages (e.g., Lamport’s timestamps – to be discussed in a later chapter). The message are ordered by the entire group. Use a centralised server. A multicast message is first sent to the server. The server assigns sequence number to the messages (the server is also called a sequencer) and send them to all the members. The messages are delivered (to the application program) in order of the sequence number.

Use a token passing (logical) ring. Only the token holder can multicast message.

Note that atomicity and ordering are two different aspects of group communications. One may have total ordering but not atomicity and vise versa. Atomic totally ordered group communication is usually expensive in terms of implementation and overheads.

  • System preserving causal order is also said to be a virtually synchronous system. An Implementation (of causal order) — Each process keeps a vector clock (V 1 , V 2 , …, Vn ). — Each message carries a vector (logical) timestamp: (V 1 , V 2 , …, Vn ). Where Vk increments each time process P (^) k multicast a message. — When message with timestamp (V 1 , V 2 , …, Vn ) from Pj is received. The message is accepted if Vj = L (^) j + 1, and Vi <= L (^) i Where (L 1 , L 2 , …, Ln ) is the local vector clock. And the local clock is set to (V 1 , V 2 , …, Vn). Otherwise, the message is held back until the condition is satisfied.

Design Issues to be Considered

  1. Design your client-user interface
    1. Group Information Inquiring
    2. Joint Group
    3. …….
  2. Use TCP or UDP ( I choose TCP)
  3. Functional Specification 3.1 Membership related service

a) create a group b) Joint group c) Leave group d) remove group ……. 3.2. Multicast related services a) send message to a group b) message ordering (consistant order) 3.3 Miscellanceous Services a) group information inquiring

  1. Architectural Relationship between Clients and Server(s) server client1 client 2 … clientn
  2. Architectural Relationships among processes and threads each client owns a process and the client process may contain several threads a thread sending group related command a thread sending message related command. the server owns a process that contains several threads each primitive corresponds to a tread, e.g., join group create a group …… send a message to a group Note that, you can use other ways to organize threads. Whatever you do, give reasons in the report.
  3. Client-to-Server Protocol If many functions are on server side. How does the clients call them? 1#1gname --create a group with the name gname 1#gid -- join the group with group in “gid” 6#gid#meg -- send message “msg” to the group “gid”
  4. Atomicity and fault tolerance, etc will be considered in semester B. However, you have to leave some “space” for that.