Date: Sun, 2 Feb 1997 12:36:00 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: proff@suburbia.net Cc: hackers@FreeBSD.ORG Subject: Re: slow ypserv problem Message-ID: <199702021736.MAA02624@skynet.ctr.columbia.edu> In-Reply-To: <19970202074803.4702.qmail@suburbia.net> from "proff@suburbia.net" at Feb 2, 97 06:48:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, proff@suburbia.net had to walk into mine and say: > > Of all the gin joints in all the towns in all the world, Tom Samplonius > > had to walk into mine and say: > > > > > > > > On Sat, 1 Feb 1997, Steve wrote: > > > > > > > On Sat, 1 Feb 1997, Tom Samplonius wrote: > > > > > Bill knows. > > > > > > > > > > ypserv was completely re-written for 2.2. > > > > Darn straight. > > (etc) > > What happened to the NIS+ support someone posted to here > a few months ago? Er... I don't know what you're talking about. I'm still working on NIS+, but first I have to deal with Secure RPC. Lately I've been hampered a bit by Real Work (tm) though. (Getting my backup system working reliably with my new DLT tape drive holds a slightly higher priority. :) What I've done so far is put together a libnisdb database backend for the NIS+ server, created a few pieces of the nislib client support, and started work on rpc.nisd. Mostly I've been testing my rpc.nisd with a slowlaris machine to see what sort things slowlaris expects the server to do (it's not always obvious from the protocol definition). I reached the point where I can create, modify, lookup and destroy NIS+ directories, and create, lookup and destroy NIS+ tables. I also have rudimentary support for callbacks, although I need to do some more work to make the callback mechanism work correctly. (It was while playing with callbacks that I realized just how thread-oriented NIS+ is supposed to be. It is possible that a client may initiate a callback which will cause the server to transmit a stream or records, one at a time. This is actually done 'backwards' by having rpc.nisd do a clnt_call() to set up a new connection to the client program and transmit records with clnt_call(). But clnt_call() actually does two things: it sends a request, then it waits for an answer. It is the client's responsibility to send an answer for each request, but it doesn't always send an answer right away. For example, in the nis_list() case, the client may get a record from rpc.nisd, then turn around and use the data from that record to make _another_ NIS+ call to the server. But the server is still waiting for the client to send a reply to its callback, hence it will be unable to service the client's other request, and the server and client will become deadlocked. Sun's solution for this is to handle callbacks in a seperate thread. My solution, which is still only half implemented, is to essentially split the clnt_call() in half: the first part of the call (transmitting the record) is done right away, then it returns and the socket from the CLIENT handle is added to the descriptor list monitored by the select() loop in svc_run(). This lets the server handle the replies asynchronously and avoids blocking without the use of threads.) There's still one puzzle I haven't completely solved yet, which has to do with entry attributes. An entry in a table is supposed to posess its own attributes, like owner, creation time, modification time, and time to live (ttl) value. But the entry_obj structure in the NIS+ protocol definition does not have fields to suppor this: it only has fields for the per-column data and an en_type field for the object type. An entry can have extra attributes _if_ it is encapsulated in an nis_object structure, but entries are not stored by the database backend as nis_objects. This being the case, where does the server store this extra per-entry attribute information? My half-assed solution for this is to abuse the en_type field to hold the data in a specially encoded form (the entry type is always the same as the table type anyway, so you can always fudge it back up before returning the entry to the client). But something tells me there's a better way. Anyway. I still have to implement the transaction logging, the public key updating routines, and the replication handling. I also need to make sure the security model (access rights, etc...) actually works the way Sun says it should. Hopefully I can fill in the rest of the client library at the same time. Then I can do nis_cachemgr and all the damned command line utilities. Lastly, Sun implements 'DNS forwarding' as a seperate process (rpc.nisd_resolv). I'm not sure I want to do it this way. We'll see. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702021736.MAA02624>