|
|
RPC service
|
|
rpc_svc_reg(3N) rpc_svc_reg(3N) NAME
rpc_svc_reg: rpc_reg(), svc_reg(), svc_unreg(), svc_auth_reg(), xprt_register(), xprt_unregister() - library routines for registering servers SYNOPSIS
DESCRIPTION
These routines are a part of the RPC library which allows the RPC servers to register themselves with (see rpcbind(3N)), and associate the given program and version number with the dispatch function. When the RPC server receives a RPC request, the library invokes the dispatch routine with the appropriate arguments. The HP-UX implementation of RPC only supports the X/Open Transport Interface (XTI). Applications that are written using the Transport Layer Interface (TLI) and wish to use RPC, must convert their application to XTI. Routines See rpc(3N) for the definition of the data structure. Register program prognum, procedure procname, and version versnum with the RPC service package. If a request arrives for program prognum, version versnum, and procedure procnum, procname is called with a pointer to its parameter(s); procname should return a pointer to its result(s). inproc is the XDR function used to decode the parameters while outproc is the XDR function used to encode the results. Procedures are registered on all available transports of the class nettype. See rpc(3N). This routine returns if the registration succeeded, otherwise. Associates prognum and versnum with the service dispatch procedure, dispatch. If netconf is NULL, the service is not registered with the ser- vice. For example, if a service has already been registered using some other means, such as (see inetd(1M)), it will not need to be registered again. If netconf is non-zero, then a mapping of the triple [prognum, versnum, to is established with the local service. The routine returns if it succeeds, and otherwise. Remove from the service, all mappings of the triple [prognum, versnum, all-transports] to network address and all mappings within the RPC service package of the double [prognum, versnum] to dispatch routines. Registers the service authentication routine handler with the dispatch mechanism so that it can be invoked to authenticate RPC requests received with authentication type cred_flavor. This interface allows developers to add new authentication types to their RPC applications without needing to modify the libraries. Service implementors usually do not need this routine. Typical service application would call after registering the service and prior to calling When needed to process an RPC credential of type cred_flavor, the handler procedure will be called with two parameters and is expected to return a valid value. There is no provision to change or delete an authentication handler once registered. The routine returns if the registration is successful, if cred_flavor already has an authentication handler registered for it, and otherwise. After RPC service transport handle xprt is created, it is registered with the RPC service package. This routine modifies the global variable (see rpc_svc_calls(3N)). Service implementors usually do not need this routine. Before an RPC service transport handle xprt is destroyed, it unregisters itself with the RPC service package. This routine modifies the global variable (see rpc_svc_calls(3N)). Service implementors usually do not need this routine. MULTITHREAD USAGE
Thread Safe: Yes Cancel Safe: Yes Fork Safe: No Async-cancel Safe: No Async-signal Safe: No These functions can be called safely in a multithreaded environment. They may be cancellation points in that they call functions that are cancel points. In a multithreaded environment, these functions are not safe to be called by a child process after and before These functions should not be called by a multithreaded application that supports asynchronous cancellation or asynchronous signals. SEE ALSO
inetd(1M), rpcbind(1M), select(2), rpc(3N), rpc_svc_calls(3N), rpc_svc_create(3N), rpc_svc_err(3N), rpcbind(3N). rpc_svc_reg(3N)
