greg@umbc3.umbc.edu (Greg Sylvain,Lib 007,3929,) (06/05/91)
Hi,
I have two unrelated questions that I haven't been able to figure out,
I hope some has a clue ?
Q-1) I'm trying to build amd/amq (an automounter daemon), it builds ok, and
to run ok. (I can remount fs's with it with out any ptoblems). But amq talks
to amd via rpc port number 300019. The port is supposedly registered, it's
in the /etc/rpc file correctly. But whenever I invoke amq, it comes beck with
rpc not registered (or something to that effect). And sure enough, when I
run /usr/etc/rpcifo -p the port isn't registerd. I thought all I had to do was
put a line in /etc/rpc to register the port. Does anyone have an idea why
rpc isn't seeing the new entry in the file ? (I've tried rebooting and nothing
changed)
Q-2) If your on a cluster server, is there a way you can tell when/how a cnode
dies (loses contact with the server) ? This would seem to be so unusual of a
request.
Any reply would be appreciated, Thanks,
greg
Greg Sylvain
Academic Computing Services
Systems Programmer
UUCP: ...!{uunet}!umbc5!greg
Internet (Arpa) : greg@umbc5.umbc.edu
BITNET : GREGS@UMBCmarkl@hpbbi4.HP.COM (#Mark Lufkin) (06/05/91)
> Q-1) I'm trying to build amd/amq (an automounter daemon), it builds ok, and > to run ok. (I can remount fs's with it with out any ptoblems). But amq talks > to amd via rpc port number 300019. The port is supposedly registered, it's > in the /etc/rpc file correctly. But whenever I invoke amq, it comes beck with > rpc not registered (or something to that effect). And sure enough, when I > run /usr/etc/rpcifo -p the port isn't registerd. I thought all I had to do was > put a line in /etc/rpc to register the port. Does anyone have an idea why > rpc isn't seeing the new entry in the file ? (I've tried rebooting and nothing > changed) I am going to be completely useless at answering your question and (hopefully) make a suggestion that may help you. First, sorry I don't really know enough about SUN RPC to be able to answer a techncial question on it. What I would like to suggest is the use of NCS (Networking Computing System). This is available on HP platforms and is fully supported. It has also been chosen as the RPC for use in the OSF Distributed Computing Environment (this was announced yesterday and includes a lot more than RPC). Note that SUN RPC was also a contender for use but was not picked for a variety of technical reasons. Enough of my little speech (I guess I am entitled to it as I support this stuff). > > Q-2) If your on a cluster server, is there a way you can tell when/how a cnode > dies (loses contact with the server) ? This would seem to be so unusual of a > request. I guess you are talking about HPUX diskless here (also part of OSF/DCE incidently). The easiest is that the client will panic and give you a message saying why it panic'ed. Diskless nodes don't core dump (unless they have local swap) so you will not be able to get more information on why the crash occurred. If you are only interested in why / how it loses contact with the server this is more of a networking problem. You would then need a network manager / analyser of some sort. As far as server is concerned it simply that it can no longer communicate with the client. > > Any reply would be appreciated, Thanks, > greg > Greg Sylvain > Academic Computing Services > Systems Programmer > > UUCP: ...!{uunet}!umbc5!greg > Internet (Arpa) : greg@umbc5.umbc.edu > BITNET : GREGS@UMBC > ---------- Mark Lufkin WG-EMC OS Technical Support HP GmbH, Boeblingen These are obviously all my own opinions and don't necessarily reflect those of HP etc. etc.
tpm@eng.cam.ac.uk (tim marsland) (06/05/91)
[long, boring, and contains flames. hit n now..] >In article <...> Greg Sylvain writes: >> Q-1) I'm trying to build amd/amq (an automounter daemon), it builds ok, and >> to run ok. (I can remount fs's with it with out any ptoblems). Greg, For those that missed the original context, `amd' is a value added replacement for the automount(8) program (currently shipped with SunOS) that automatically mounts and unmounts NFS (and other filesystem types) on demand. `amq' is a program which queries and reports the state of the `amd' daemon using the same SunRPC mechanism as NFS does. Disclaimer: I have the source of amd, (which was recently posted to comp.sources.unix by its author, Jan-Simon Pendry <jsp@doc.ic.ac.uk> ) but I have not installed it on HP hardware, so please excuse vagueness.. Hopefully my two cents worth will aid Greg in tracking down the problem. First off, the SunRPC model has - surprise - clients and servers, and a set of procedures implemented by the server and called by clients via Remote Procedure Call stubs. In this context, `Amd' behaves both as an NFS nfs/mount server and as an AMQ server. `Amq' is an AMQ client program that allows you to query the state of `amd.' >> But amq talks to amd via rpc port number 300019. 300019 is the program number used for amq/amd comms. `Amd' registers that it will be prepared to listen to `amq' by giving the /etc/portmap process the tuple [prog, vers, prot, port]. in other words, `amd' tells the portmapper `i can service remote procedure calls for program number prog, version vers, using the given protocol (tcp or udp) and the given internet port number.' clients who wish to use a given service then use the portmapper to find the appropriate protocol and port number. See the portmap(1M) entry in the fine manual. >> The port is supposedly registered, it's >> in the /etc/rpc file correctly. i.e. that's not quite `registering' amq, it simply allows routines like getrpcent(3C) to bind name to program number. the portmapper process really holds the registration when `amd' runs i.e. it maps [prog, vers] to internet portnumber so that the client program (amq) can actually open an internet socket to talk to the right `amd' server port. >> But whenever I invoke amq, it comes beck with >> rpc not registered (or something to that effect). And sure enough, when I >> run /usr/etc/rpcifo -p the port isn't registerd. I thought all I had to do was >> put a line in /etc/rpc to register the port. Does anyone have an idea why >> rpc isn't seeing the new entry in the file ? (I've tried rebooting and nothing >> changed) If client% /usr/etc/rpcinfo -p server doesn't show `amq' it is a problem with `amd.' I think that it's because `amd' isn't registering its AMQ service properly with your portmapper. Note that the /etc/rpc lookup takes place only where you invoke rpcinfo. It would be useful to give OS version numbers, and to say exactly where you are running the amd/amq programs e.g. both on the cluster server or what? Have you tried mailing jsp@doc.ic.ac.uk? I'd be grateful if you could mail me or post the real answer, whatever it may be. In article <1720006@hpbbi4.HP.COM> markl@hpbbi4.HP.COM (#Mark Lufkin) writes: Mark, ** Flame on ** > I am going to be completely useless at answering your question and > (hopefully) make a suggestion that may help you. First, sorry I don't > really know enough about SUN RPC to be able to answer a techncial > question on it. What I would like to suggest is the use of NCS > (Networking Computing System). What!!? Are you suggesting that Greg rewrites `amd' to use NCS?? > This is available on HP platforms .. But so is SunRPC. We use it on the large number of HP machines here for a variety of purposes. > and is fully supported. Are you saying that you _don't_ support SunRPC? We have HP manuals that describe how to use it, so we went ahead and used it. It is the basis of your NFS implementation, and surely HP are going to continue to support NFS for a year or two yet? [You can also get the source of SunRPC for free from various archive sites, even if you're not an academic institution.] > It has also been chosen as the RPC for use > in the OSF Distributed Computing Environment (this was announced > yesterday and includes a lot more than RPC). Note that SUN RPC was > also a contender for use but was not picked for a variety of technical > reasons. Yawn. Look, I've got nothing against HP/Apollo NCS, and I've heard that it has some technical improvements over SunRPC. Great - I have some tentative thought of my own about SunRPC failings. However, I've never heard the particular technical arguments in favour of NCS (despite asking HP in January), and *would* be grateful if someone would post a brief account of the differences, or points me at an HP document. Enquiring minds want to know. > .. Enough of my little speech (I guess I am entitled to it as I > support this stuff). To be brutal, I get the feeling that your posting is simply OSF posturing. Fine, there are certainly people out there that like this sort of tosh -- but please don't post it out in the guise of a non-answer to some guy's question about a vaguely related problem. If you want to advertise NCS vs. SunRPC in this forum, *please* tell us why it's better. ``Because OSF says it is'' is not really good enough! ** Flame off ** Greg, >> Q-2) If your on a cluster server, is there a way you can tell when/how a cnode >> dies (loses contact with the server) ? This would seem to be so unusual of a >> request. > Diskless nodes don't core dump (unless > they have local swap) so you will not be able to get more information > on why the crash occurred. That's really neat. Any reason why? > ... As far as the > server is concerned it simply that it can no longer communicate with > the client. Quite. Getting the client to say ``I've died'' is a bit tricky once its dead :-) Detecting when it dies is a bit more feasible - you can periodically ping the client workstation to check that it's still responding. There are a few ways to do this: a) Use the ping(1M) program which sends ICMP ECHO packets at the client. ICMP messages are handled at a low level in the kernel, so ping'ing will work even when the machine is fairly broken (though not when its actually dead :) or early on after a reboot. e.g. server% /etc/ping client -n 1 b) By convention, every SunRPC program responds to a ping procedure. So, as an alternative, you can try ping'ing one of the RPC server processes running on the client using rpcinfo (in this example, rpc.statd needs to be running on the client): e.g. server% /usr/etc/rpcinfo -u client status c) Use the rlb(1M) program (remote loopback diagnostics) which is very comprehensive, though i've never really used it in anger. The first two can also be done programmatically, allowing timeouts to be specified. In fact I think that (b) is the way `amd' determines if a file server is alive before automounting a directory from it. >> Greg Sylvain >> Academic Computing Services >> Systems Programmer >> >> UUCP: ...!{uunet}!umbc5!greg >> Internet (Arpa) : greg@umbc5.umbc.edu >> BITNET : GREGS@UMBC > >Mark Lufkin >WG-EMC >OS Technical Support >HP GmbH, Boeblingen > >These are obviously all my own opinions and don't necessarily reflect >those of HP etc. etc. tim marsland, <tpm@cam.eng.ac.uk> information engineering division, cambridge university engineering dept.,
markl@hpbbi4.HP.COM (#Mark Lufkin) (06/05/91)
> What!!? Are you suggesting that Greg rewrites `amd' to use NCS?? I must admit I have no idea what 'amd' is or where it comes from but the idea is not as stupid as you might think ... it does not take long to convert a program (it has been done in house ... could have something to do with the fact that we are pushing NCS now though and having SUNrpc based applications does not look good :-) Being serious, the exercise is not as stupid as you would like to imply. > Yawn. Look, I've got nothing against HP/Apollo NCS, and I've heard that > it has some technical improvements over SunRPC. Great - I have some > tentative thought of my own about SunRPC failings. However, I've never > heard the particular technical arguments in favour of NCS (despite asking > HP in January), and *would* be grateful if someone would post a brief > account of the differences, or points me at an HP document. Enquiring > minds want to know. > > To be brutal, I get the feeling that your posting is simply OSF posturing. > Fine, there are certainly people out there that like this sort of tosh > -- but please don't post it out in the guise of a non-answer to some guy's > question about a vaguely related problem. If you want to advertise > NCS vs. SunRPC in this forum, *please* tell us why it's better. > ``Because OSF says it is'' is not really good enough! OK, so I asked for that a bit. I promise I don't work for OSF though. It was not OSF posturing but I would admit to NCS posturing - it is my opinion though that NCS is better. The reasons why NCS was chosen over the Netwise/SUNrpc offering were: There is a fuller description the following documents: Apollo NCA and SUN ONC: A Comparison (Nathaniel Mishkin) A Comparison of Commercial RPC Systems (Joshua Levy) A response to the above by Nathaniel Mishkin I do not have any of these electrponically - if I find them I will make them available - if anyone else has them, they could do the same (the last two were in comp.misc some time back. Just as a summary of why OSF chose NCS over SUNrpc/Netwise offering: - minimal programming complexity - NCS adheres more closely to the local procedure model making it easier to use. - the RPC protocol is clearly defined and not subject to change by the user (Netwise RPCTool IDL compiler). - uniform transport behaviour. NCS does not depend on transport characteristics. An example - if UDP is chosen as the underlying protocol limits are imposed on the size and number of arguments as well as the reliebility. NCS allows the choice of a variety of transports without affecting the operation. - allows integration with a threading package, also integrated with authentication s/w (Kerberos). Also allows a 'pipe' capability for bulk transfer of data. > >> Q-2) If your on a cluster server, is there a way you can tell when/how a cnode > >> dies (loses contact with the server) ? This would seem to be so unusual of a > >> request. > > > Diskless nodes don't core dump (unless > > they have local swap) so you will not be able to get more information > > on why the crash occurred. > > That's really neat. Any reason why? Easy ... the crash is put into swap, the swap is on the server which we have just lost contact with ... > > > ... As far as the > > server is concerned it simply that it can no longer communicate with > > the client. > > Quite. Getting the client to say ``I've died'' is a bit tricky once its > dead :-) Detecting when it dies is a bit more feasible - you can > periodically ping the client workstation to check that it's still > responding. There are a few ways to do this: Actually, diskless DOES use pinging. When it finds that it has not any messages from a client it sends a ping package and expects a reply. If after a kernel definable number of tries the client still has not responded, then it is declared dead. > > > tim marsland, <tpm@cam.eng.ac.uk> > information engineering division, > cambridge university engineering dept., > ---------- OK, that's enough from me. I will now shut for a while and try not to offend anyone else (seems to be difficult these days). I will admit to being biased in my opinions but then so is everyone else (and the world would be a boring place if we weren't). tschuess, Mark Lufkin Tech Support HP GmbH
tpm@eng.cam.ac.uk (tim marsland) (06/05/91)
In article <1720009@hpbbi4.HP.COM> markl@hpbbi4.HP.COM (#Mark Lufkin) writes: >> What!!? Are you suggesting that Greg rewrites `amd' to use NCS?? > > I must admit I have no idea what 'amd' is or where it comes > from but the idea is not as stupid as you might think Well, speaking for myself, not knowing anything about a program generally stops me from posting replies to people's questions about it :-) > ... it does > not take long to convert a program (it has been done in house ... > could have something to do with the fact that we are pushing NCS > now though and having SUNrpc based applications does not look > good :-) Applications like NFS you mean? Or is that going now? This is one of the more serious undercurrents which underlies this discussion. > Being serious, the exercise is not as stupid as you would > like to imply. Also being serious, I concur that one can often rewrite programs to use different RPC paradigm's. However, I'm not exactly sure how useful gratuitous rewriting is in the context of the original query (summary: "How do I register amq?"). Note that `amd' is only(!) about 17000+ lines of cunning C that has been ported to at least ten different vendors Unix variants ;-) However, the main reason why I was so shocked by the suggestion (and shocked I was) is not the idea of rewriting per se, but more that `amd' is itself an NFS server i.e. it has to be based around SunRPC. Specifically, rewriting `amd' to use a different RPC paradigm would have meant rewriting the NFS code in the kernel of the local machine and of all the mount daemons of the file servers it was accessing, *as* *well* *as* amd itself. Quite a few man-months ``conversion'' work for poor Greg methinks :-) Perhaps now you understand why I tried to imply rewriting was stupid in this case, and the general ferocity of my flame? > The reasons why NCS was chosen over the Netwise/SUNrpc offering were: > There is a fuller description the following documents: > > Apollo NCA and SUN ONC: A Comparison (Nathaniel Mishkin) > > A Comparison of Commercial RPC Systems (Joshua Levy) > A response to the above by Nathaniel Mishkin > > I do not have any of these electrponically - if I find them I will > make them available - if anyone else has them, they could do the > same (the last two were in comp.misc some time back. and > Just as a summary of why OSF chose NCS over SUNrpc/Netwise offering: > ... This is more like it Mark -- thanks. I'd very much like to read these documents, and your summary of the factors that influenced the decision is much appreciated. >> >> Q-2) If your on a cluster server, is there a way you can tell when/how a cnode >> >> dies (loses contact with the server) ? This would seem to be so unusual of a >> >> request. >> >> > Diskless nodes don't core dump (unless >> > they have local swap) so you will not be able to get more information >> > on why the crash occurred. >> >> That's really neat. Any reason why? > > Easy ... the crash is put into swap, the swap is on the server which > we have just lost contact with ... That's not what I meant i.e. the crash might not be *caused* by a network error. For example, there might have been a bug in a pseudo-device I was trying to add to the kernel (say). Is it still the case that the client can't core dump when it panics for non-network-related problems? > I will admit to being biased in my opinions but then so is > everyone else (and the world would be a boring place if we weren't). Yes, but.. this is a technical forum, not a marketing forum :), so we've all got to try and keep our opinions under control wherever possible :-) > OK, that's enough from me. I will now shut for a while and try > not to offend anyone else (seems to be difficult these days). Hey, no problem Mark -- it's been fun. Just hope everyone else has enjoyed it. I'll shut up now too. tim marsland, <tpm@cam.eng.ac.uk> information engineering division, cambridge university engineering dept.,
news@brchh104.bnr.ca (news) (06/05/91)
In article 1720009@hpbbi4.HP.COM Mark Lufkin writes: > In article 8606@rasp.eng.cam.ac.uk tim marsland writes: >> Yawn. Look, I've got nothing against HP/Apollo NCS, and I've heard that >> it has some technical improvements over SunRPC. Great - I have some >> tentative thought of my own about SunRPC failings. However, I've never >> heard the particular technical arguments in favour of NCS (despite asking >> HP in January), and *would* be grateful if someone would post a brief >> account of the differences, or points me at an HP document. Enquiring >> minds want to know. >> >> To be brutal, I get the feeling that your posting is simply OSF posturing. >> Fine, there are certainly people out there that like this sort of tosh >> -- but please don't post it out in the guise of a non-answer to some guy's >> question about a vaguely related problem. If you want to advertise >> NCS vs. SunRPC in this forum, *please* tell us why it's better. >> ``Because OSF says it is'' is not really good enough! Well, some time has passed since Mark's response to the request; I wanted to present another point of view. Disclaimer: I'm an engineer for Netwise, and my opinions may not be impartial. In any case, my opinions do not reflect any official position of Netwise. > OK, so I asked for that a bit. I promise I don't work for OSF though. > It was not OSF posturing but I would admit to NCS posturing - it is > my opinion though that NCS is better. > > The reasons why NCS was chosen over the Netwise/SUNrpc offering were: > There is a fuller description the following documents: > > Apollo NCA and SUN ONC: A Comparison (Nathaniel Mishkin) > > A Comparison of Commercial RPC Systems (Joshua Levy) > A response to the above by Nathaniel Mishkin > > I do not have any of these electrponically - if I find them I will > make them available - if anyone else has them, they could do the > same (the last two were in comp.misc some time back. At the time, Mishkin was an employee of Apollo. In June of 1989, Tony Andrews, a Netwise employee, posted "A Review of Current Product Offerings", which has various benchmarks of current Sun/Apollo/Netwise offerings (I believe this was to comp.protocols.tcp-ip). This would be an appropriate document to look at, along with the ones that Mark mentioned. I will re-post it if desired. > Just as a summary of why OSF chose NCS over SUNrpc/Netwise offering: Mark's reference appears to be the "OSF Distributed Computing Equipment Rationale", dated May 14, 1990, from the Open Software Foundation. OSF is specifying an entire Distributed Computing environment--Naming, Security, Threads, as well as RPC. OSF chose NCS 2.0: "...a joint submission of Digital and Hewlett-Packard." This is not a shippable product. It is not appropriate to compare an unavailable NCS 2.0 against Sun's RPCGen. Sun has announced availability of the Netwise RPC Tool in the Second Half of 1990 ("Distributed Computing Road Map--An Outlook on the Future of Open Network Computing" Sun Microsystems, Inc., dated April 30, 1990). A comparison of NCS 2.0 and these new Sun offerings would be appropriate. Based on Mark's highlights from the OSF document: > - minimal programming complexity - NCS adheres more closely to > the local procedure model making it easier to use. I'm not sure what this is a reference to. Both NCS 1.x and the current Netwise RPC Tool have been generating C code for client and server stubs. These stubs handle packing and unpacking the data and networking operations, making an RPC call appear as if it's a local subroutine call. Both will continue to use stub generation in future versions. Besides the joint Netwise/Sun submission to OSF, Sun submitted RPCGen separately. Perhaps the OSF is talking about the non-transparency of RPCGen. I would be interested in seeing some clarification of what OSF is talking about--it's not clear from their Rationale. > - the RPC protocol is clearly defined and not subject to change by > the user (Netwise RPCTool IDL compiler). The OSF rationale is referring to Netwise's customization feature. Both the server and client sides of an RPC call are modeled as a state machines. A user can add hooks to modify what happens in a particular state or change the state transitions. There are 2 implications in the OSF document. The first is that customization of the RPC specification is not valuable. Netwise's expericnce has been that customization is important to our customers. The second implication is that customization creates possible interoperability problems. Since this is a technical forum, an appropriate way to explain Netwise's philosophy is to provide a real example of customization. I'll apologize in advance for glossing over some of the details, but hopefully the general point will be clear: One of our customers wanted to have a multi-tasking server (i.e., a server that can handle requests from multiple clients simultaneously). Multi-tasking servers are quite straightforward in a UNIX environment--Netwise provides "canned" code to provide a multitasking server for UNIX systems. Unfortunately, our customer's OS does not support the concept of copying network file descriptors on a fork() call. Saying the problem another way, the OS's fork() mechanism does not permit multiple processes to use the same address for connections. Netwise created customization so that a client's first RPC call would instead perform two RPC calls. The first call is to the named server, which returns the (unnamed) address of a worker to the client. The second call is from the client to the worker which establishes a connection for subsequent RPC calls. From the point of view of the applications programmer, a single RPC call has been performed. The customization, which is declared in the RPC Specification File, provides a means of containment for the custom functionality of the call. The application *could* have made a separate RPC call to get the address of the worker, but that doesn't permit the applications programmer to maintain the abstraction of the RPC call. If our customer moves his server to a UNIX environment, he can simply remove the customization, re-compile, and run with no modification to the application code. An RPC Toolkit could include some "standard" set of customization features, but which ones would you include? Customizations could include modifications to security, naming, auditing, asynchronous RPC calls, etc. Which do you include with the Toolkit? Netwise felt the only sane way to proceed was with having the users add whatever they want -- an "Open Architecture" approach. Finally, it's not clear what an "RPC protocol" is or what it would mean to change one. My feeling is that the RPC Specification File is specifying the protocol for some set of RPC calls. The customization is part of that Specification File. Sure, you could create a buggy customization. In Toolkits where RPC customization wasn't available, you could have bugs in the application code performing the customization. Bugs are bugs. Again, the difference is that Netwise contains the customization in one centralized location, providing a layer of abstraction for the applications programmer. This may well wind up being a *religious issue* about RPC technology. > - uniform transport behaviour. NCS does not depend on transport > characteristics. An example - if UDP is chosen as the underlying > protocol limits are imposed on the size and number of arguments > as well as the reliebility. NCS allows the choice of a variety of > transports without affecting the operation. The Apollo NCS 1.x uses datagram-oriented transports. Unfortunately, RPC needs to be built on top of a reliable transport. Apollo built their own protocol on top of datagram transports to achieve reliability. In some (all?) systems, these are not implemented in the kernel. It's unclear why a home-brew reliable transport would be superior to using the reliable transport provided by the OS. It could be slightly faster in some environments, particularly if few packets are lost. Tuning in more hostile environments would probably be difficult, particularly since the application may not have access to the appropriate real-time tools that kernel code does. Finally, there is the added code space for implemting the reliable transport on top of the datagram transport. In the NCS2.0 product, my understanding is that they will use both connection-oriented and datagram-oriented transports (Mike?). The next-generation Netwise tool will be offering datagram transports. However, we will be offering the raw datagram functionality to the application--message delivery will be unreliable and message size will be limited to the size permitted by the transport. This is what OSF means when they say we don't have uniform transport behavior. Why did we make this choice? Basiclly, we feel that a connection-oriented transport is the way to go. However, if an applications writer is willing to deal with the reliability and space constraints, then a raw datagram transport interface can be used. Assuming appropriate reliability characteristics for the datagram transport, we will have much lower overhead per packet than either flavour of NCS2.0. Finally, a datagram transport is necessary to support broadcast. NCS2.0 will run on top of either a datagram or a connection-oriented transport, but you're really getting a connection-oriented service in either case. Mike: what will NCS2.0 do WRT broadcast? Will it be available with both types of transport? If broadcast is not available under connection-oriented transports, won't this constitute non-uniform transport behavior? If a Netwise user really wanted unlimited data under datagrams, he could add it with customization :-). > - allows integration with a threading package, also integrated with > authentication s/w (Kerberos). Also allows a 'pipe' capability for > bulk transfer of data. The Netwise tool has customization that would give the analogue to 'pipe'. The callback customization would allow a server to throttle data coming from the client. Sun's RPC currently does not have multithread support; they have announced multithread support in the Second Half of 1991. They will have Kerberos in the first half of 1991 (see document reference above). Netwise's current products support multithreaded applications (with the restriction that each connection be accessed within a single thread). What does NCS2.0 do in environments that don't support multiple threads?
fkittred@spca.bbn.com (Fletcher Kittredge) (06/13/91)
In article <2985@brchh104.bnr.ca> news@brchh104.bnr.ca (news) writes: >Netwise's current products support multithreaded applications (with >the restriction that each connection be accessed within a single >thread). What does NCS2.0 do in environments that don't support >multiple threads? Maintaining a thread to connection mapping is a major restriction, one which I would prefer not to program around. Not only is it really non-portable, but it is really non-portable in a way which seriously constrains the architecture of my application. NCS2.0 is part of the DCE. An additional part of the DCE is the CMA threads package. The CMA threads package is just a user space implementation of POSIX 1003.4b draft 4 threads (pthreads). For environments which have native pthreads, such as OSF/1, you just use native pthreads. For environments without native threads, you use CMA. The supposed strength of the DCE is the integration of the parts; it is unlikely that anyone would use NCS 2.0 RPC without the other DCE parts. I seriously consider native threads to be more of a boon to distributed applications writers than RPCs. Hopefully over time, most environments will have POSIX threads, so this *major* advantage of the DCE over Netwise will go away... By the way, HP employees being ignorant of what the automounter and amd are is sooo symptomatic of their failings in the areas of distributed computing. The HP lack of tools for a distributed environment gives one the sense that they really don't use a distributed heterogenous environment in house. They don't even have an automounter in their next release and it took them till 1990 to get rdump! Also, rewriting a working application which uses Sun RPC to use NCS RPC is a stupid idea. There really isn't much difference between the two. regards, fletcher Fletcher Kittredge BBN Software Products 150 CambridgePark Dr, Cambridge, MA. 02140 617-873-3465 / fkittred@bbn.com / fkittred@das.harvard.edu
mishkin@apollo.com (Nathaniel Mishkin) (06/28/91)
First, maybe it has something to do with our site's recent upgrading of its newe software or maybe it has to do with the recent solar flares (now THAT would be appropriate :-), but I've seen a ton of postings (many duplicates) relating to RPC on comp.sys.sun that are in fact from the spring and summer of LAST YEAR. These posting I think originated on comp.protocols.misc. I don't know why I (or anyone else) is seeing them now. I don't read this group regularly so maybe I missed some explanation. In article <3794@brchh104.bnr.ca>, fkittred@spca.bbn.com (Fletcher Kittredge) writes: >The supposed strength of the DCE is the integration of the parts; it is >unlikely that anyone would use NCS 2.0 RPC without the other DCE parts. This isn't quite accurate. NCS 2.0 RPC (aka DCE RPC) uses the pthreads API. The DCE contains a relatively portable implementation (aka DCE Threads) of the pthreads API. Having just DCE RPC and DCE Threads (or an alternate implementation of the pthreads API) you can do useful stuff. The next most likely piece of the DCE you'd want is the DCE Directory service, which supports a replicated, read/write, hierarchical (i.e., UNIX-like) namespace. This service is a big aid to RPC application developers. Beyond that, having the DCE Security service would be useful if you want to do *authenticated* RPC. Several snapshots (including a "developer's kit") of the DCE have been shipped by OSF over the last year. These snapshots (which consist of source code) are available to OSF members and DCE licensees. >I seriously consider native threads to be more of a boon to distributed >applications writers than RPCs. Hopefully over time, most environments >will have POSIX threads, so this *major* advantage of the DCE over Netwise >will go away... Gosh, this seems like an apples-to-oranges comparison. Threads are just a plain useful programming paradigm. There's no intrinsic relationship between RPC and threads. >By the way, HP employees being ignorant of what the automounter and amd >are is sooo symptomatic of their failings in the areas of distributed >computing. The HP lack of tools for a distributed environment gives one >the sense that they really don't use a distributed heterogenous >environment in house. They don't even have an automounter in their next >release and it took them till 1990 to get rdump! I'm afraid I must have missed the original posting so as far as I know, it could have been stupid as all get out. But let's not tar an entire company and its strategy for supporting distribution applications based on one posting. >Also, rewriting a working application which uses Sun RPC to use NCS >RPC is a stupid idea. Probably true, at least in some cases. >There really isn't much difference between the two. Just so this doesn't go un-noted: YOU may think there are no differences, but many people (myself included) think there are a number of important differences. I really recommend people look at the existing documentation for the two systems. Also, with your vaporware hats on, you should look at documents describing future product versions of these systems. -- -- Nat Mishkin Cooperative Object Computing Division / East Hewlett-Packard Company mishkin@apollo.hp.com -------