JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
ONC+ Developer's Guide     Oracle Solaris 11 Express 11/10
search filter icon
search icon

Document Information

Preface

1.  Introduction to ONC+ Technologies

2.  Introduction to TI-RPC

3.  rpcgen Programming Guide

4.  Programmer's Interface to RPC

5.  Advanced RPC Programming Techniques

poll() on the Server Side

Broadcast RPC

Batching

Authentication

AUTH_SYS Authentication

AUTH_DES Authentication

AUTH_KERB Authentication

Authentication Using RPCSEC_GSS

RPCSEC_GSS API

RPCSEC_GSS Routines

Creating a Context

Changing Values and Destroying a Context

Principal Names

Setting Server Principal Names

Generating Client Principal Names

Freeing Principal Names

Receiving Credentials at the Server

Cookies

Callbacks

Maximum Data Size

Miscellaneous Functions

Associated Files

gsscred Table

/etc/gss/qop and /etc/gss/mech

Using Port Monitors

Using inetd

Using the Listener

Multiple Server Versions

Multiple Client Versions

Using Transient RPC Program Numbers

6.  Porting From TS-RPC to TI-RPC

7.  Multithreaded RPC Programming

8.  Extensions to the Sun RPC Library

9.  NIS+ Programming Guide

A.  XDR Technical Note

B.  RPC Protocol and Language Specification

C.  XDR Protocol Specification

D.  RPC Code Examples

E.  portmap Utility

F.  Writing a Port Monitor With the Service Access Facility (SAF)

Glossary

Index

Using Port Monitors

RPC servers can be started by port monitors such as inetd and listen. Port monitors listen for requests and spawn servers in response. The forked server process is passed the file descriptor 0 on which the request has been accepted. For inetd, when the server is done, it can exit immediately or wait a given interval for another service request. See also Appendix F, Writing a Port Monitor With the Service Access Facility (SAF).

For listen, servers should exit immediately after replying because listen() always spawns a new process. The following function call creates a SVCXPRT handle to be used by the services started by port monitors.

transp = svc_tli_create(0, nconf, (struct t_bind *)NULL, 0, 0)

nconf is the netconfig structure of the transport from which the request is received.

Because the port monitors have already registered the service with rpcbind, the service does not need to register with rpcbind. The service must call svc_reg() to register the service procedure.

svc_reg(transp, PROGNUM, VERSNUM, dispatch,(struct netconfig *)NULL)

The netconfig structure is NULL to prevent svc_reg() from registering the service with rpcbind.

For connection-oriented transports, the following routine provides a lower level interface:

transp = svc_fd_create(0, recvsize, sendsize);

A 0 file descriptor is the first argument. You can set the value of recvsize and sendsize to any appropriate buffer size. A 0 for either argument causes a system default size to be chosen. Application servers that do not do any listening of their own use svc_fd_create().

Using inetd

Entries in /etc/inet/inetd.conf have different formats for socket-based, TLI-based, and RPC services. The format of inetd.conf entries for RPC services follows.

Table 5-3 RPC inetd Services

Service
Description
rpc_prog/vers
The name of an RPC program followed by a / and the version number or a range of version numbers.
endpoint_type
One of dgram (for connectionless sockets), stream (for connection mode sockets), or tli (for TLI endpoints).
proto
May be * (for all supported transports), a net type, a net ID, or a comma separated list of net type and net ID.
flags
Either wait or nowait.
user
Must exist in the effective passwd database.
pathname
Full path name of the server daemon.
args
Arguments to be passed to the daemon on invocation.

For example:

rquotad/1 tli rpc/udp wait root /usr/lib/nfs/rquotad rquotad

For more information, see the inetd.conf(4) man page.

Using the Listener

Use pmadm to add RPC services:

pmadm -a -p pm_tag -s svctag -i id -v vers \
     -m `nlsadmin -c command -D -R prog:vers`

The arguments are:

-a

adds a service

-p pm_tag

specifies a tag associated with the port monitor providing access to the service

-s svctag

server's identifying code

-i id

the /etc/passwd user name assigned to service svctag

-v ver

the version number for the port monitor's database file

-m

specifies the nlsadmin command to invoke the service. nlsadmin can have additional arguments. For example, to add version 1 of a remote program server named rusersd, a pmadm command would be:

# pmadm -a -p tcp -s rusers -i root -v 4 \
   -m `nlsadmin -c /usr/sbin/rpc.ruserd -D -R 100002:1`

The command is given root permissions, installed in version 4 of the listener database file, and is made available over TCP transports. Because of the complexity of the arguments and options to pmadm, use a command script or the menu system to add RPC services. To use the menu system, type sysadm ports and choose the -port_services option.

After adding a service, the listener must be re-initialized before the service is available. To do this, stop and restart the listener, as follows. rpcbind must be running.

# sacadm -k -p pmtag
# sacadm -s -p pmtag

For more information, such as how to set up the listener process, see the listen(1M), pmadm(1M), and sacadm(1M) man pages. Also see How the TCP/IP Protocols Handle Data Communications in System Administration Guide: IP Services.