You may need to use the "Transport Independent" RPC
(ti-rpc) calls rather than the older calls that are more widely
available. I remember having that gripe ages ago, but thought
that it finally got fixed when SVr4 came out. Of course they
depend on streams and similar non-Linux things...
Alternatively, you can do low level registration to the RPC
infrastructure using svc_register(), then implement your own
smarter rpc binding policy that doesn't use portmap. When
I've needed to do nontrivial things with ONC RPC, that kind
of solution has been all too essential. The portmap model is
"one machine, one service", which is annoyingly inappropriate
except for certain simple application classes.
- Dave
----- Original Message -----
From: "Ben Greear" <greearb@xxxxxxxxxxxxxxx>
To: <netdev@xxxxxxxxxxx>
Sent: Wednesday, November 07, 2001 9:41 AM
Subject: [OT] Question on RPC & portmap
> Suppose I have a program that uses RPC. It registers it's protocol
> and starts talking with another machine....
>
> Now, I want to run both (many) processes on the same machine to
> simulate a bigger system. The problem seems to be that when an
> RPC program registers, it cannot (easily?) register itself as bound
> only to a particular IP/interface...
>
> I can hack the portmap code if I have to, but I definately
> can't change the RPC API.
>
> Does anyone have any ideas, or any pointers to more appropriate forums
> in which to ask this question?
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@xxxxxxxxxxxxxxx> <Ben_Greear AT excite.com>
> President of Candela Technologies Inc http://www.candelatech.com
> ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
>
>
|