| Previous | Next |
| RPC_E_CALL_CANCELED | RPC_E_CANTCALLOUT_INASYNCCALL |
RPC_E_CANTPOST_INSENDCALL
Remote Procedure Call (RPC) for the C and C++ programming languages is designed to help meet the needs of developers working on the next generation of software for Windows operating systems.
RPC is a powerful, robust, efficient, and secure interprocess communication (IPC) mechanism that enables data exchange and invocation of functionality residing in a different process. That different process can be on the same machine, on the local area network, or across the Internet. This section explains the RPC programming model and the model for distributed systems that can be implemented using RPC.
RPC fully supports 64-bit Windows. There are three types of processes: native 32-bit processes, native 64-bit processes, and 32-bit processes running under the 32-bit process emulator on a 64-bit system (often referred to as WOW64 processes). For more information about WOW64, see Running 32-bit Applications. Using RPC, developers can transparently communicate between different types of process; RPC automatically manages process differences behind the scenes.
RPC was initially developed as an extension to OSF RPC. With the exception of some of its advanced features, RPC is interoperable with other vendors' implementations of OSF RPC.
Overview of an RFC Application
A traditional application is a single program running on a single computer system, where a procedure and its caller execute in the same address space. In contrast, the client-server model for distributed applications embodies a client program and a server program, usually running on different systems of a network. The client makes a request to the server, which is usually a continuously running daemon process, and the server sends a response back to the client.
The remote procedure call (RFC) mechanism is the simplest way to implement client-server applications, because it keeps the details of network communications out of your application code. The idea is that each side behaves, as much as possi ble, the way it would within a traditional application: the programmer on the client side issues a call, and the programmer on the server side writes a procedure to carry out the desired function. To convey the illusion that you are working in a single address space, some hidden code has to handle all the networking. Many related issues are also involved, such as converting data between formats for dif ferent systems, and detecting communication errors.
The server s RFC runtime library receives the remote procedure call and hands the client information to the server stub. The server stub invokes the remote proce dure in the server application.