Re: [Tsp-devel] Re: Weird behavior of ONC RPC rpcbind daemon F7

[Eric Noulard]

2007/8/30, Frederik Deweerdt <address@hidden>:
> On Thu, Aug 30, 2007 at 04:50:51PM +0200, Eric Noulard wrote:
> > I've updated the bug.
> > I think I found the reason.
> >
> > We are linked again glibc ONC-RPC whereas we may/should link
> > against tirpc.
> The libs have the same name isn't it?

No in fact they don't.

Current glibc aka libc.[a|so] include rpclib API (<rpc/rpc.h>)

tirpc is named libtirpc.[a.so] and "seems" (as far as I understand)
to be API compatible.

> Are they binary compatible?

More or less.
The short answer is NO you need to recompile+relink.
But yes since "old" rpc lib should be able to use the
new implementation of rpc services, the portmapper.
Since it "should" be compatible I did file
a bug to rpcbind:
http://sourceforge.net/tracker/index.php?func=detail&aid=1784838&group_id=201237&atid=976751

More detailed answer follows:

Our [classical] usage of ONC-RPC is twofold

   1) the RPC lib which is an implementation of the API you find in <rpc/rpc.h>.
       the libs includes XDR encoding API xdr_xxx
       see:
          xdr(3) and rpc(3)
          ftp://ftp.rfc-editor.org/in-notes/rfc1057.txt (ONC-RPC v2)
          ftp://ftp.rfc-editor.org/in-notes/std/std67.txt (XDR)

   2) the RPC portmapper service
         specified both in
         ftp://ftp.rfc-editor.org/in-notes/rfc1057.txt (ONC-RPC v2)
         and in a revised form in
         ftp://ftp.rfc-editor.org/in-notes/rfc1833.txt (RPCBIND for ONC-RPC v2)

         The portmapper is implemented as a unix daemon
         (or Windows service). In the same package you usually
         get the rpcinfo command for inspecting the
         RPC server(s) currently registered in the portmapper.
         see portmap(8) and/or rpcbind(8) and rpcinfo(8)

We are linked with the lib 1) and we call 2) the portmapper
through the rpc lib 1).

With the "Old fashioned" ONC-RPC
         1) lib rpc is in glibc
         2) the portmapper is called portmap
With the "New" TI-RPC
         1) lib rpc is a standalone /usr/lib/libtirpc.so.1
         2) the portmapper is called rpcbind

Even more detailed info about TI-RPC in:
"ONC+ Developer's Guide" (doc Solaris 10) de Sun
http://docs-pdf.sun.com/816-1435/816-1435.pdf

> If not, shouldn't this be implemented as a new command transport layer
> (a la xmlrpc)?

May be interesting since in TI-RPC, TI means Transport Independent
current target of Transport are IPV4 (UDP and TCP) and IPV6 (UDP and TCP).
The main motivation of TI-RPC seems to be NFSv4 which NEEDS
IPV6 support which was not taken into account in ONC-RPC.

That said I don't know if we should "replace" onc-rpc with ti-rpc
in the long run or add ti-rpc as a supplementary default command
transport layer.

I would say that for backward compatibility reason adding
a new ti-rpc handler would be better.

I've just discovered the TI idea and I would say that this is
almost the "same" functional idea as our multi-command transport layer
(oncrpc, xml-rpc etc...)


-- 
Erk