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)