Date: Mon, 26 Mar 2001 19:57:10 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Bill Paul <wpaul@FreeBSD.ORG> Cc: current@FreeBSD.ORG Subject: Re: Fixing ypbind with TI-RPC Message-ID: <20010326195710.M9431@fw.wintelcom.net> In-Reply-To: <20010327000456.6B15D37B71A@hub.freebsd.org>; from wpaul@FreeBSD.ORG on Mon, Mar 26, 2001 at 04:04:56PM -0800 References: <20010327000456.6B15D37B71A@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Bill Paul <wpaul@FreeBSD.ORG> [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? 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? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010326195710.M9431>