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
SYNOPSISDESCRIPTION
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 applica‐
tion 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, ver‐
sion 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, dis‐
patch. If netconf is NULL, the service is not registered with
the service. For example, if a service has already been regis‐
tered 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 cre‐
dential 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 authentica‐
tion 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 ALSOinetd(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)