Communication via remote procedure calls

The UAPs in an OpenTP1 system can communicate with other UAPs using remote procedure calls (RPCs). A UAP process uses an RPC to request a service from another UAP process, and the UAP process that received the request uses an RPC to return the processing result to the requesting UAP.

Figure 2-1 shows how processing is performed in a client/server configuration.

Figure 2-1 Overview of communication in a client/server configuration

[Figure]

#1: TP1/Client is a client-specific product that requests services from an OpenTP1 server.; For details about TP1/Client, see 2.2.2 Using OpenTP1 client software on workstations and PCs and 3.5 OpenTP1 client facility (TP1/Client).

#2: With the OpenTP1 interface, RPCs can be used to communicate with a server UAP behind a firewall. However, when requests cross a firewall, the server UAP cannot be included in the transaction processing. For details about communicating with a UAP behind a firewall, see 3.7.1 Example of using the remote API facility.

Organization of this subsection: (1) Client UAP and server UAP; (2) Transactional RPCs; (3) Remote procedure calls supported by OpenTP1; (4) Client/server configuration communication protocols; (5) TCP_NODELAY

(1) Client UAP and server UAP

The UAPs that request and provide services, respectively, are in a client/server relationship. The UAP on the requesting side is referred to as a client UAP and the UAP on the service-providing side is referred to as a server UAP.

For details about UAPs, see 2.6 User application programs in OpenTP1 systems.

(2) Transactional RPCs

OpenTP1 also provides programmers with functions that cause OpenTP1 to treat an RPC as a transaction. For example, coding dc_trn_begin() before dc_rpc_call() will cause OpenTP1 to handle the processing following the dc_rpc_call() call as a transaction. In such a case dc_rpc_call() is said to be a transactional RPC. The transaction extends over the period from when a service is requested to when the results are returned. OpenTP1 can handle transactional RPCs that cause processing over multiple nodes.

(3) Remote procedure calls supported by OpenTP1

The following describes the OpenTP1 interface provided for client/server communications.

(a) OpenTP1 interface

The OpenTP1 interface is a communication method that enables services to be requested using OpenTP1 library functions.

(b) Compatibility with the X/Open interface

In addition to the native OpenTP1 functions, OpenTP1 also supports remote procedure calls and functions compatible with the X/Open interface. Programmers can thus code OpenTP1 client/server applications by writing applications using the standard X/Open interface. Communication is possible via the XATMI and TxRPC interfaces.

For details about client/server communications, see 3.2 Processing in an OpenTP1 client/server configuration.

(4) Client/server configuration communication protocols

(5) TCP_NODELAY

TOpenTP1 provides functionality that guarantees no-delay data transmission even during a wait for a response to data already sent.^# This functionality can be enabled by using the TCP_NODELAY option for the socket (INET domain) that OpenTP1 uses for inter-node communication.

You can specify whether to use the TCP_NODELAY option for data transmission by using the ipc_tcpnodelay operand in the schedule service definition, the user service definition, or the user service default definition. Note that if this option is used, the efficiency of sending data in INET domain communication may be degraded and the network load may increase. Before using the option, carefully consider whether the option is necessary by taking into account the ipc_sendbuf_size operand, the ipc_recvbuf_size operand, the network bandwidth, and other factors.

#: This functionality is implemented by disabling the Nagle algorithm in TCP/IP.