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
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.
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.
The following describes the OpenTP1 interface provided for client/server communications.
The OpenTP1 interface is a communication method that enables services to be requested using OpenTP1 library functions.
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.
For the client/server configuration communication protocol of OpenTP1, TCP/IP can be used. You need not to be aware of the communication protocol in UAP processing.
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.