* Bill Paul <[EMAIL PROTECTED]> [010326 16:05] wrote:
> Ok. Friday I sat down and tried to make the -m option to ypbind work
> correctly using the new TI-RPC code. Unfortunately, my test machine
> chose that day to eat itself. Even more unfortunately, it was an AMD
> 900Mhz Thunderbird. Today, I started working on another box and managed
> to get things to work, but there are some problems that still need
> solving. I need some input to decide how to do this.
> The problem is with the code in yp_ping.c. This module contains a special
> version of clntudp_call() which has been modified in two ways:
> 1) If the XDR encode routine is specified as NULL, it skips the transmit
>    portion of clntudp_send() and jumps straight to receiving and decoding
>    the reply.
> 2) When processing a reply, the routine omits the check of the transaction
>    ID, so that the reply will be processed even if its XID doesn't match
>    the XID of the request that was last sent.
> This is done so that we can send a bunch of YPPROC_DOMAIN_NONACK requests
> to different servers, each with a different transaction ID, then wait to
> see who replies first. Distinguishing the servers based on the XID gets
> around the case where the server is multihomed and replies on an interface
> other than the one where it received the original RPC. This is basically
> an asynchronous RPC, where the request and response are handled separately
> rather than in the context of a single clntudp_call().
> Anyway, now that we have the TI-RPC library, the magic clntudp_a_call()
> routine needs to be changed to a clnt_dg_a_call(). Unfortunately, when I
> tried to do this, I ran into a serious problem:
> - The clnt_dg.c module has several module-wide lock variables which are
>   shared between the create/call/destroy methods. Trying to set up a
>   private call method won't work, because the lock variables are static,
>   hence not exported from the clnt_dg.o object module. As a hack I created
>   a separate clnt_dg.c module which I linked directly into a test ypbind
>   binary, but this is not what I consider a proper solution.
> Basically, I can't do things the way I did them with the older RPC code
> because of the threading/mutex locks. Even building a separate clnt_dg.o
> module with modifications was harder than it needed to be because the
> clnt_dg.c code #includes special header files within the libc source
> (src/lib/libc/include) which aren't available if you aren't building
> the world.
> The solution I'm leaning towards at the moment is adding the necessary
> hacks to src/lib/libc/rpc/clnt_dg.c in such a way that they can be enabled
> when needed with a special CLSET flag using clnt_control(). Then I can
> rip out the custom call method code from yp_ping.c entirely. I'm a little
> reluctant to do this since I was under the impression that creating a
> custom method should still work, but it looks as if this problem is
> endemic even to the original Sun TI-RPC code, not just us.
> Comments? Questions? Pie?


Why can't you just enable sigio on the reply socket, send all the
requests with a 0 timeout and then wait for a signal to either
interrupt the sending or to notify you when you complete sending?

Your solution seems awfully complex for what seems to be a simple
problem; doing a directed broadcast and taking the first answer you
get back.

Is the whole reason you need to do this because you're using the
xid to differentiate between the servers?

Represent yourself, show up at BABUG http://www.babug.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to