




Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Inter process communicatiom (Ipc)
Typology: Exams
1 / 8
This page cannot be seen from the preview
Don't miss anything!





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
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.
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.
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.
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.
Design Issues to be Considered
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