Will@cup.portal.com (Will E Estes) (10/26/90)
Given the widespread availability of RPC technology in the UNIX world, I am wondering why haven't more vendors offered commercial applications that make use of the RPC technology? What are the technical or business issues that keep process modeling or simulation or other mathematically intensive applications from making use of the power of a number of machines on the network? Note that I am talking about applications that vendors write and resell to end-users and not about homegrown applications. Thanks, Will Estes (sun!portal!cup.portal.com!Will)
RBNTJC@ROHVM1.BITNET (Thomas J Cozzolino) (10/27/90)
I can't understand why there aren't more RPC-based commercial applications out there. We took a monolithic FORTRAN molecular modelling program and partitioned it to run graphics on a DN-3000 and a minimization on an Alliant mini-super around 2 years ago (way back to NCS ver. 1.0). It wasn't that much fun at the time, but it worked. Maybe most software companies aren't prepared for the support that would be involved in running a "shink-wrapped" application over a combination of many vendors' equipment. Another big fear is the Sun vs. HP/Apollo RPC issue that so many of us are tired of hearing about. Let's get some applications already| Oh well. Maybe when Motif and DCE become realities... (?)
joshua@athertn.Atherton.COM (Flame Bait) (10/30/90)
RBNTJC@ROHVM1.BITNET (Thomas J Cozzolino) writes: > I can't understand why there aren't more RPC-based commercial > applications out there. If you knew the answer to this question, you could make lots of money selling it. Programmers and end users are crying out for distributed platforms and applications. At the same time, vendors are supplying pretty good RPC systems. Yet, there are few RPC based distributed applications. > Maybe most software companies aren't prepared for the support that would be > involved in running a "shink-wrapped" application over a combination of many > vendors' equipment. Perhaps, but there are lots of socket based distributed applications, which should have the same problems. > Another big fear is the Sun vs. HP/Apollo RPC issue that so many of us > are tired of hearing about. Let's get some applications already| Again, perhaps, but that those fears seem to be limited to Sun and HP. Each afraid they might loose, I'm not sure that applications writers really care that much. I didn't. The other "usual suspects" for the lack of RPC applications are lack of debugging tools and lack of partitioning tools. But I'm not sure I buy into that, either. My best guess is that it is inertia. UNIX communications programming has always been an arcane specialty. The people who did it all started with sockets, and are continuing to use what they know best. As new people start doing communications programming they will use RPC more and more. The arcane aspect also makes companies warry of taking existing applications and distributing them. Unless the performance is really bad or the application really needs data somewhere else, they are unlikely to take the time and efford to use RPC. (And of course the applications can't be that slow or that in need of other data or they would not have been written in the first place. Catch-22.) Another problem is standards. Not the Sun/HP conflict, but RFCs. These "Request For Comment" documents define various standards, de facto standards and targets. They specify all (or almost all) protocols as data passed over UDP and TCP. Therefore, it is impossible to write a standard conforming SNMP, SMTP, or ARP servers (for example) using RPC. This encourages people to use sockets for other server programs they need to write. It would be nice if we could see some RFC protocols defined as RPC specifications, but there are lots of practical problems. Summary: I dunno why people don't use RPC for more applications work. I did, and it worked fine. BTW: I read and liked your (Cozzolino's) paper describing your distributed application. Joshua Levy (joshua@atherton.com)