From owner-freebsd-current  Mon Mar 26 16: 5: 1 2001
Delivered-To: freebsd-current@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 618)
	id 6B15D37B71A; Mon, 26 Mar 2001 16:04:56 -0800 (PST)
Subject: Fixing ypbind with TI-RPC
To: current@freebsd.org
Date: Mon, 26 Mar 2001 16:04:56 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20010327000456.6B15D37B71A@hub.freebsd.org>
From: wpaul@FreeBSD.ORG (Bill Paul)
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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?

-Bill

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message