*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> rpcgen (1)              


rpcgen(1)							     rpcgen(1)

NAME    [Toc]    [Back]

     rpcgen - an RPC protocol compiler

SYNOPSIS    [Toc]    [Back]

     rpcgen infile
     rpcgen [-C	cppcmd<b>]	[-Dname<b>[=value<b>]] [-T] [-P] [-I | -K secs<b>] infile
     rpcgen -c|-h|-l|-m|-t [-P]	[-o outfile <b>] infile
     rpcgen -s nettype <b>[-o outfile<b>] infile
     rpcgen -n netid <b>[-o outfile<b>] infile

DESCRIPTION    [Toc]    [Back]

     rpcgen is a tool that generates C code to implement an RPC	protocol.
     rpcgen will produce file to be used with libc [see	intro.3n(1)].  To
     produce file to be	used with libnsl see rpcgen_tli(1).  The input to
     rpcgen is a language similar to C known as	RPC Language (Remote Procedure
     Call Language).

     rpcgen is normally	used as	in the first synopsis where it takes an	input
     file and generates	up to four output files.  If the infile	is named
     proto.x, then rpcgen will generate	a header file in proto.h, XDR routines
     in	proto_xdr.c, server-side stubs in proto_svc.c, and client-side stubs
     in	proto_clnt.c.  With the	-T option, it will also	generate the RPC
     dispatch table in proto_tbl.i.

     The server	created	can be started both by the port	monitors (for example,
     inetd or listen) or by itself.  When it is	started	by a port monitor, it
     creates servers only for the transport for	which the file descriptor 0
     was passed.  The name of the transport must be specified by setting up
     the environment variable PM_TRANSPORT.  When the server generated by
     rpcgen is executed, it creates server handles for all the transports
     specified in NETPATH environment variable,	or if it is not	set, it
     creates server handles for	all the	visible	transports from	/etc/netconfig
     file.  Note:  the transports are chosen at	run time and not at compile
     time.  When the server is self-started, it	backgrounds itself by default.
     A special symbol, RPC_SVC_FG, can be defined at compilation time to make
     the server	process	run in foreground.

     The second	synopsis provides special features which allow for the
     creation of more sophisticated RPC	servers.  These	features include
     support for user provided #defines	and RPC	dispatch tables.  The entries
     in	the RPC	dispatch table contain:
	  o  pointers to the service routine corresponding to that procedure,
	  o  a pointer to the input and	output arguments
	  o  the size of these routines
     A server can use the dispatch table to check authorization	and then to
     execute the service routine; a client library may use it to deal with the
     details of	storage	management and XDR data	conversion.

     The other three synopses shown above are used when	one does not want to
     generate all the output files, but	only a particular one.	Some examples
     of	their usage is described in the	EXAMPLE	section	below.	When rpcgen is
     executed with the -s option, it creates servers for that particular class

									Page 1

rpcgen(1)							     rpcgen(1)

     of	transports.  When executed with	the -n option, it creates a server for
     the transport specified by	netid.	If infile is not specified, rpcgen
     accepts the standard input.

     The C preprocessor, cc -E [see cc(1)], is run on the input	file before it
     is	actually interpreted by	rpcgen.	 For each type of output file, rpcgen
     defines a special preprocessor symbol for use by the rpcgen programmer:

     RPC_HDR	 defined when compiling	into header files
     RPC_XDR	 defined when compiling	into XDR routines
     RPC_SVC	 defined when compiling	into server-side stubs
     RPC_CLNT	 defined when compiling	into client-side stubs
     RPC_TBL	 defined when compiling	into RPC dispatch tables

     Any line beginning	with `%' is passed directly into the output file,
     uninterpreted by rpcgen.

     For every data type referred to in	infile,	rpcgen assumes that there
     exists a routine with the string xdr_ prepended to	the name of the	data
     type.  If this routine does not exist in the RPC/XDR library, it must be
     provided.	Providing an undefined data type allows	customization of XDR

     The following options are available:

     -C	cppcmd
	  Run the preprocessor command,	cppcmd,	instead	of the default,	cpp.

     -c	  Compile into XDR routines.

	  Define a symbol name.	 Equivalent to the #define directive in	the
	  source.  If no value is given, value is defined as 1.	 This option
	  may be specified more	than once.

     -h	  Compile into C data-definitions (a header file).  The	-T option can
	  be used in conjunction to produce a header file which	supports RPC
	  dispatch tables.

     -I	  Compile support for inetd(1M)	in the server side stubs.  Such
	  servers can be self-started or can be	started	by inetd.  When	the
	  server is self-started, it backgrounds itself	by default.  A special
	  define symbol	RPC_SVC_FG can be used to run the server process in
	  foreground, or the user may simply compile without the -I option.

	  If there are no pending client requests, the inetd servers exit
	  after	120 seconds (default).	The default can	be changed with	the -K
	  option.  All the error messages for inetd servers are	always logged
	  with syslog(3).

									Page 2

rpcgen(1)							     rpcgen(1)

	  Note:	 this option is	supported for backward compatibility only.  By
	  default, rpcgen generates servers that can be	invoked	through

     -K	secs
	  By default, services created using rpcgen wait 120 seconds after
	  servicing a request before exiting.  That interval can be changed
	  using	the -K flag.  To create	a server that exits immediately	upon
	  servicing a request, -K 0 can	be used.  To create a server that
	  never	exits, the appropriate argument	is -K -1.

	  When monitoring for a	server,	some portmonitors, like	listen(1M),
	  always spawn a new process in	response to a service request.	If it
	  is known that	a server will be used with such	a monitor, the server
	  should exit immediately on completion.  For such servers, rpcgen
	  should be used with -K -1.

     -l	  Compile into client-side stubs.

     -m	  Compile into server-side stubs, but do not generate a	main routine.
	  This option is useful	for doing callback-routines and	for users who
	  need to write	their own main routine to do initialization.

     -n	netid
	  Compile into server-side stubs for the transport specified by	netid.
	  There	should be an entry for netid in	the netconfig database.	 This
	  option may be	specified more than once, so as	to compile a server
	  that serves multiple transports.

     -o	outfile
	  Specify the name of the output file.	If none	is specified, standard
	  output is used (-c, -h, -l, -m, -n, -s and -t	modes only).

     -P	  Generate prototyped XDR and stub function declarations and
	  definitions suitable for ANSI	C and C++. The prototypes for the
	  client- and server-side stubs	are different; their declarations in
	  the generated	header file are	conditionally-compiled with the	values
	  _RPCGEN_CLNT or _RPCGEN_SVC.	If you write your own client or	server
	  code,	you must define	the appropriate	value in your source files
	  before including the generated header	file. Using the	example	above,
	  the file for client code should use:

	       #define _RPCGEN_CLNT
	       #include	"proto.h"

	  and the file for server code should use:

	       #define _RPCGEN_SVC
	       #include	"proto.h"

									Page 3

rpcgen(1)							     rpcgen(1)

     -s	nettype
	  Compile into server-side stubs for all the transports	belonging to
	  the class nettype.  The supported classes are	netpath, visible,
	  circuit_n, circuit_v,	datagram_n, datagram_v,	tcp, and udp [see
	  rpc(3N) for the meanings associated with these classes].  This
	  option may be	specified more than once.  Note:  the transports are
	  chosen at run	time and not at	compile	time.

     -t	  Compile into RPC dispatch table.

     -T	  Generate the code to support RPC dispatch tables.

     The options -c, -h, -l, -m, -s and	-t are used exclusively	to generate a
     particular	type of	file, while the	options	-D, -P,	and -T are global and
     can be used with the other	options.

NOTES    [Toc]    [Back]

     The RPC Language does not support nesting of structures.  As a workaround,
 structures	can be declared	at the top-level, and their name used
     inside other structures in	order to achieve the same effect.

     Name clashes can occur when using program definitions, since the apparent
     scoping does not really apply.  Most of these can be avoided by giving
     unique names for programs,	versions, procedures and types.

     The server	code generated with -n option refers to	the transport
     indicated by netid	and hence is very site specific.

EXAMPLE    [Toc]    [Back]

     The following example:

	  rpcgen -T prot.x

     generates all the five files:  prot.h, prot_clnt.c, prot_svc.c,
     prot_xdr.c	and prot_tbl.i.

     The following example sends the C data-definitions	(header	file) to the
     standard output.

	  rpcgen -h prot.x

     To	send the test version of the -DTEST, server side stubs for all the
     transport belonging to the	class datagram_n to standard output, use:

	  rpcgen -s datagram_n -DTEST prot.x

     To	create the server side stubs for the transport indicated by netid <b>tcp,

	  rpcgen -n tcp	-o prot_svc.c prot.x

									Page 4

rpcgen(1)							     rpcgen(1)

SEE ALSO    [Toc]    [Back]

     cc(1), rpgen_tli(1)

									PPPPaaaaggggeeee 5555
[ Back ]
 Similar pages
Name OS Title
rpcgen OpenBSD RPC protocol compiler
rpcgen NetBSD Remote Procedure Call (RPC) protocol compiler
abicc IRIX ABI C compiler
NCC IRIX 32-bit C++ compiler
cc Tru64 C compiler
yacc IRIX yet another compiler-compiler
getprotobyname Tru64 Get a protocol entry by protocol name
getprotobyname_r Tru64 Get a protocol entry by protocol name
tic IRIX terminfo compiler
cc NetBSD GNU project C and C++ Compiler (gcc-2.95)
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service