tr@samadams.princeton.edu (Tom Reingold) (08/24/90)
At my job, we are about to write some applications for running over TCP/IP on Unix hosts. We would like to think ahead with portability in mind. One day, our code may run on a non-unix host. And if we write it in sockets, we may run against a version that is built upon and supports only STREAMS. Or will we? 1. What implementations are built on STREAMS? 2. Are they new or old? 3. Are all TCP/IP suites done with sockets nowadays? 4. Is there a reason to consider implementing our code in STREAMS? 5. Currently, our hosts run System V release 3.[23] and have both libraries. Which is "the way" to go? -- Tom Reingold tr@samadams.princeton.edu rutgers!princeton!samadams!tr 201-577-5814 "Brew strength depends upon the amount of coffee used." -Black&Decker
JAZBO@BROWNVM.BROWN.EDU ("James H. Coombs") (08/25/90)
> >Date: Fri, 24 Aug 90 01:54:52 GMT >From: Tom Reingold <cs!samadams.princeton.edu@PRINCETON.EDU> > >At my job, we are about to write some applications for running over >TCP/IP on Unix hosts. We would like to think ahead with portability in >mind. >3. Are all TCP/IP suites done with sockets nowadays? Definitely not. >5. Currently, our hosts run System V release 3.[23] and have both >libraries. Which is "the way" to go? Sun now states that no new applications should be developed at the socket level. They recommend 1) RPC or 2) TIL(?--which starts with SunOS 4.1). RPC has several advantages: 1. The library is available through ftp. 2. You can work at a high level with minimal concern for networking details. 3. Client and server can be bound together into a single process without modifying the code (although you may want to eliminate the code that would normally establish a connection). 4. Various transport mechanisms may be used under the RPC interface. The package supports sockets and raw buffers. Future versions will probably use TIL(?), which in turn provides some independence from lower levels. 5. The application-specific protocol can be developed relatively invisibly by defining c-type structures. The programmer does not have to think about sending a long, using htonl(), etc. If it is convenient to change a long to a short, then rebuilding the application should update both the client and the server (assuming the proper make dependencies). One is less likely to try to send a long to a process that is waiting for a short. On the down side: 1. It is a little trickier to do something like have the server fork immediately after accepting a connection. 2. There may remain a need to drop down to the transport layer for such details as keepalive options on sockets. Whatever you decide, you should take a good look at RPC. I haven't been fully converted yet, but I will certainly be influenced by the library even if I decide to stay with sockets (and my object-oriented server building block). --Jim Dr. James H. Coombs Chief Architect Institute for Research in Information and Scholarship (IRIS) Brown University, Box 1946 Providence, RI 02912 jazbo@brownvm.bitnet Acknowledge-To: <JAZBO@BROWNVM>
rodk@germania.Sun.COM (Rod King (Sun HQ Consulting)) (08/25/90)
In article <2117@rossignol.Princeton.EDU> tr@samadams.princeton.edu (Tom Reingold) writes: >At my job, we are about to write some applications for running over >TCP/IP on Unix hosts. We would like to think ahead with portability in >mind. One day, our code may run on a non-unix host. And if we write >it in sockets, we may run against a version that is built upon and >supports only STREAMS. Or will we? With respect to Unix systems, System V r4 (SVr4) presents the Transport Level Interface (TLI). This is the transport layer interface that will obsolete sockets; there will be STREAMS modules existing underneath the interface. TLI is modeled after the ISO Transport Service Definition (ISO 8072), so presumably, if your non-unix host has a similiar facility, porting shouldn't be that bad. >3. Are all TCP/IP suites done with sockets nowadays? SVr4 (or at least Sun's version) will be using STREAMS. I'm not sure of the commercial availability of TLI in a Unix system (SunOS 4.1, the current version, does NOT support it). By the way, if your application can use some sort of RPC facility, then you can be shielded from all of this. If you want some TLI documentation, refer to "Network Programming Guide", from Sun Microsystems (part 800-3850-10). Good luck! Rod
rja7m@paisley.cs.Virginia.EDU (Ran Atkinson) (08/25/90)
The network interfaces specified by the System V Interface Definition and by the X/Open consortium are based on the STREAMS with TLI (Transport Level Interface) that were originally developed at AT&T. Since the System V socket-library is built on top of STREAMS/TLI, an application written to use sockets will probably be slower on a System V system that the same application written using STREAMS/TLI natively. In general I think that the STREAMS/TLI approach is better because details of the transport protocol used are appropriately hidden unlike BSD sockets. Certainly a lot of good software is out there using sockets and I don't think that the socket library will disappear anytime soon, but for new software I really think that STREAMS/TLI are a better approach -- especially if developing for a System V platform.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (08/25/90)
In article <9008242107.AA19843@ucbvax.Berkeley.EDU> JAZBO@BROWNVM.BROWN.EDU ("James H. Coombs") writes: > > From: Tom Reingold <cs!samadams.princeton.edu@PRINCETON.EDU> [ portability: sockets vs. streams ] > > Which is "the way" to go? > Sun now states that no new applications should be developed at the socket > level. They recommend 1) RPC or 2) TIL(?--which starts with SunOS 4.1). RPC > has several advantages: For comparison, here's how my auth package measures up to your criteria. > 1. The library is available through ftp. The same is true of auth. /comp.sources.unix/volume22/auth/* on uunet. > 2. You can work at a high level with minimal concern for networking details. The same is true of auth. auth-util/* are sample applications, including (for example) a shell script adaptation of trivial inews. 76 lines, with comments and better error checking than the original. > 3. Client and server can be bound together into a single process without > modifying the code (although you may want to eliminate the code that > would normally establish a connection). auth is based on a client-server model, not a single-process RPC model, so this does not apply. See below. > 4. Various transport mechanisms may be used under the RPC interface. The same is true of auth. The c.s.unix version of auth is based on sockets; the same interface can be set up over practically any two-way communications medium. You don't have to change code to use this. Note that auth uses RFC 931 for authentication; it eliminates mail and news forgery above TCP. auth-util includes a small set of wrappers that you can put around sendmail to achieve this extra security with no effort. > 5. The application-specific protocol can be developed relatively invisibly > by defining c-type structures. The auth programmer doesn't have to bother thinking about a protocol. He need only use the software techniques he's comfortable with for writing data to a file. The same techniques work for transferring data over the network through auth. > On the down side: > 1. It is a little trickier to do something like have the server fork > immediately after accepting a connection. This is an advantage of auth, again reflecting a difference in philosophy. auth was designed for a client-server model, so it doesn't naturally adapt to single procedures run on different machines as part of the same program. RPC was designed for remote procedure call, so it doesn't naturally adapt to the (perhaps more common) client-server case. > 2. There may remain a need to drop down to the transport layer for such > details as keepalive options on sockets. The same is true for auth. This is only a reflection of the ``problem'' that a high-level interface cannot anticipate all the possible extensions of the low-level interface it's based on. > Whatever you decide, you should take a good look at RPC. I haven't been fully > converted yet, but I will certainly be influenced by the library even if I > decide to stay with sockets (and my object-oriented server building block). Whatever you decide, you should take a good look at auth. I have been fully converted, as I wrote the package. If you want to develop client-server applications and be sure that they'll work on the networks of the UNIX of the future, auth is the way to go. ---Dan
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/26/90)
In article <1990Aug24.220021.10122@murdoch.acc.Virginia.EDU>, rja7m@paisley.cs.Virginia.EDU (Ran Atkinson) writes: > ...[one of many paeans to TLI]... AT&T and others have been selling TLI with socket libraries for almost 4 years. For about that long, I've been asking about performance and compatibility. I have been privately told many unflattering stories, but have still not found any customers or vendors who will speak publically or authoratively. How fast are TCP user-process-to-user-process byte transfer over TLI? How compatible are the several socket libraries and kernel-emulators? A good TCP-with-sockets benchmark is the BRL benchmark "ttcp". Since ttcp compiles and runs directly over 4.3BSD compatible systems, it would be a good measure of both speed and compatibilty. FTP is not interesting in this context, because it measures many things, not least file system performance. Ttcp is available from several places via FTP. At least one vendor, and rumor has it others soon, ship both source and object for ttcp in standard products. Vernon Schryver vjs@sgi.com
rayan@cs.toronto.edu (Rayan Zachariassen) (08/26/90)
Regardless of what the wave of the future is, presently if you write to the TLI interface you won't be able to compile your code on a socket-only system whereas if you use the socket interface you'll be portable to most TLI systems (since they usually come with socket interface libraries). If you aren't concerned about optimal efficiency, writing to the socket interface now would be more portable.
oberman@rogue.llnl.gov (08/26/90)
In article <9008242107.AA19843@ucbvax.Berkeley.EDU>, JAZBO@BROWNVM.BROWN.EDU ("James H. Coombs") writes: > > Sun now states that no new applications should be developed at the socket > level. They recommend 1) RPC or 2) TIL(?--which starts with SunOS 4.1). RPC > has several advantages: > This is very disturbing. The Sun RPC is propriatary and I don't believe a part of the DOD protocol suite. It is also NOT the RPC in the OSF DCE. As a result I don't think software written for the SUN RPC is going to be very portable when compared to socket or stream binding. We've already seen a bit of this attitude in the Sun network management software. It supports access only by RPC, not SNMP. This makes out Suns more difficult to manage than most any box on the net which is manageable! R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
hedrick@athos.rutgers.edu (Charles Hedrick) (08/26/90)
Sun RPC is proprietary? (1) RFC 1057 documents the spec. (2) I'm reasonably sure that they posted an implementation of RPC to the network some time ago, and later on a revised version. I'm still not sure I'd write applications intended to be portable using it, but they may be right. The advantage is that you could move to ISO or anything else by changing the lower layers, and the application would not be affected. I get the impression this is the reason they made that recommendation.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/26/90)
I bet the OSF/HP/Apollo/DCE and Netwise people, to name only 2, would not be happy to be declared out of the race to define the standard RPC protocol. Last I heard from them, they are each defining The Emerging Standard. Vernon Schryver, vjs@sgi.com
imp@dancer.Solbourne.COM (Warner Losh) (08/26/90)
In article <Aug.25.22.59.16.1990.22640@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >The advantage is that you could move to ISO or anything >else by changing the lower layers, and the application would not be >affected. I get the impression this is the reason they made that >recommendation. The disadvantage is that you can't write programs like FTP or sendmail using the RPC protocol. Not programs that will interoperate with other FTP's and sendmails, at any rate. While RPC is good for some things, it is not the answer to all the networking problems. Sometimes you just gotta write at a fairly low level to interoperate with other programs. Warner -- Warner Losh imp@Solbourne.COM Me? I'm the onion rings.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (08/26/90)
In article <1990Aug26.065346.13988@Solbourne.COM> imp@dancer.Solbourne.COM (Warner Losh) writes: > In article <Aug.25.22.59.16.1990.22640@athos.rutgers.edu> > hedrick@athos.rutgers.edu (Charles Hedrick) writes: > >The advantage is that you could move to ISO or anything > >else by changing the lower layers, and the application would not be > >affected. > The disadvantage is that you can't write programs like FTP or sendmail > using the RPC protocol. Not programs that will interoperate with > other FTP's and sendmails, at any rate. auth provides that advantage without that disadvantage! Again, it was designed for client-server applications, unlike RPC. From the README: This package provides two benefits. The first is a secure user-level implementation of RFC 931, the Authentication Server; unless TCP itself is compromised, it is impossible to forge mail or news between computers supporting RFC 931. The second is a single, modular interface to TCP. Programs written to work with authtcp and attachport don't even need to be recompiled to run under a more comprehensive network security system like Kerberos, as long the auth package is replaced. The base package includes authtcp, a generic TCP client; attachport, a generic TCP server; authd, a daemon supporting RFC 931; and authuser, a compatibility library letting you take advantage of RFC 931 from older applications. authutil is a big pile of miscellany illustrating how to use auth. Directories: aport - support programs for authtcp and attachport, making server control easy; clients - various sample Internet clients, including a short shell script implementation of trivial inews (with RFC 931 security, of course); sendmail-auth - a small set of wrappers you can put around sendmail to achieve full username tracking; servers - various sample Internet servers, including a secure fingerd that wouldn't have let RTM in; tam - Trivial Authenticated Mail, a complete mail system in just 200 lines of code; and util - various short utilities that everyone should have. > While RPC is good for some things, it is not the answer to all the > networking problems. Agreed. It was designed for remote procedure call and does that quite reasonably. > Sometimes you just gotta write at a fairly low > level to interoperate with other programs. I don't think this is true: auth's interface is very high level. ---Dan
page@Eng.Sun.COM (Bob Page) (08/27/90)
> Sun RPC is propriatary What does proprietary mean to you? The RPC/XDR specs have been published for some time as RFCs 1057 (RPC) and 1014 (XDR). RPC/XDR source code (from Sun) is available for ftp from many places, like titan.rice.edu. A freely redistributable NFS implementation was built (not by Sun, but by members of the Internet community) on top of the RPC/XDR source code. Some vendors have products based on the source. > We've already seen a bit of this attitude in the Sun network management > software. It supports access only by RPC, not SNMP. Whoa -- Reality check. Last October at Interop '89, a Sun workstation running SunNet Manager was in the ACE (now Interop Inc) booth monitoring _all_ the network gateways (cisco, SynOptics, Proteon, etc). A number of vendors (SynOptics, Cabletron, Network General, Xyplex, and more) were running SunNet Manager in their respective booths to show how they interoperated with the product. The package was also running in the show's SNMP Interoperability booth. All this communication was done via SNMP, not RPC. > Disclaimer: Don't take this too seriously. I just like to improve my typing > and probably don't really know anything useful about anything. Sounds like good advice. ..bob -- Bob Page Sun Microsystems, Inc. page@eng.sun.com
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (08/27/90)
Quoth brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (in <8076:Aug2616:42:1890@kramden.acf.nyu.edu>): #auth provides that advantage without that disadvantage! Again, it was #designed for client-server applications, unlike RPC. [smiley mode on] Dear Dan, You seem to understand these things, so maybe you can help me with a little semantic problem. Every time I feed a .x file to rpcgen, it insists on spitting out client and server stubs, which I find convenient for building my distributed applications. Yet you say that RPC wasn't designed for client-server applications. I'm confused... Geoff Arnold PC-NFS architect -- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) -- To receive a full copy of my .signature, please dial 1-900-GUE-ZORK. Each call will cost you one zorkmid.
oberman@amazon.llnl.gov (08/28/90)
In article <PAGE.90Aug26161024@swap.Eng.Sun.COM>, page@Eng.Sun.COM (Bob Page) writes: > What does proprietary mean to you? The RPC/XDR specs have been > published for some time as RFCs 1057 (RPC) and 1014 (XDR). RPC/XDR > source code (from Sun) is available for ftp from many places, like > titan.rice.edu. A freely redistributable NFS implementation was built > (not by Sun, but by members of the Internet community) on top of the > RPC/XDR source code. Some vendors have products based on the source. *Sigh* This one depends on your definition of "proprietary". I once was bashed for saying that DECnet is not proprietary. It's specs have been published and are freely available. There are several implementations. But DEC owns DECnet and, until SUN places RPC in the pulic domain, SUN owns RPC. It's implementations are many and on many systems, but it is still owned by Sun. Frankly, this is a bogus issue and I should not have raised it. >> We've already seen a bit of this attitude in the Sun network management >> software. It supports access only by RPC, not SNMP. > > Whoa -- Reality check. Last October at Interop '89, a Sun workstation > running SunNet Manager was in the ACE (now Interop Inc) booth > monitoring _all_ the network gateways (cisco, SynOptics, Proteon, > etc). A number of vendors (SynOptics, Cabletron, Network General, > Xyplex, and more) were running SunNet Manager in their respective > booths to show how they interoperated with the product. The package > was also running in the show's SNMP Interoperability booth. All this > communication was done via SNMP, not RPC. Sorry, but you're wrong. The SunNet Manager recieves SNMP from all of the various sources. But I have another SNMP manager. (Several, in fact.) And guess what? I can monitor my routers (Wellfleet, cisco, Proteon) and my VMS systems. But not Suns. Why? Sun does not have an SNMP agent. When I complained to my Sun salesbeing I was told that I didn't need one. SunNet Manager accesses the data from Suns by RPC. The problem is that I don't want SunNet Manager. I personally prefer others. But the bottom line is that both streams and sockets are much more "portable" than RPC (at least for now). >>> Disclaimer: Don't take this too seriously. I just like to improve my typing >>> and probably don't really know anything useful about anything. >> >> Sounds like good advice. That's why it's there. Kevin
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (08/28/90)
In article <2487@east.East.Sun.COM> geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes: > Quoth brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (in <8076:Aug2616:42:1890@kramden.acf.nyu.edu>): > #auth provides that advantage without that disadvantage! Again, it was > #designed for client-server applications, unlike RPC. > Dear Dan, > You seem to understand these things, so maybe you can help me > with a little semantic problem. Every time I feed a .x file to rpcgen, > it insists on spitting out client and server stubs, which I find > convenient for building my distributed applications. Yet you say that > RPC wasn't designed for client-server applications. I'm confused... Dear Geoff, Let me illustrate with a trivial example: TAM, Trivial Authenticated Mail, included in authutil. It is a complete mail system, including a short shell script for sending mail, a shorter shell script daemon to receive mail on port 209, programs to set up, print, and empty your TAMbox, and scripts that convert TAM to regular mail and easy-to-read formats. It uses an extensible protocol. It is much more secure than sendmail: since it is implemented on top of auth, *all* forgeries above TCP are stopped. (Most, if not all, forgeries at a typical university are done without breaking TCP. auth completely eliminates that problem.) TAM is short enough to be bugfree, doesn't run as root, and includes the niceties you'd expect of a friendly mail system: sending you copies of what you send out, including the TCP address of received mail in case of DNS trouble, not loading the header with mounds of junk, and reading mail with no delay. All the code necessary to set up TAM, including security checks, /etc/services and /etc/rc.local modifications, and comments, takes 241 lines. That's 5K. In contrast, the README, protocol description, and man pages take 12K. Finally, TAM will be trivial to port to any communications system supporting the same interface for reliable, sequenced, two-party stream communication. Try to set up an RPC-based mail system with the features listed above. You'll quickly appreciate the fact that RPC and client-server are quite different concepts. ---Dan ``Networking systems so powerful that you can send mail around the world, with a minimal risk of forgery, in just 5K of code including the mail reader. Science fiction!'' ---hypothetical Internet guru, 1988
werner@nikhefk.UUCP (Werner Vogels) (08/28/90)
In article <Aug.25.22.59.16.1990.22640@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >Sun RPC is proprietary? (1) RFC 1057 documents the spec. (2) I'm >reasonably sure that they posted an implementation of RPC to the >network some time ago, and later on a revised version. I'm still not >sure I'd write applications intended to be portable using it, but they >may be right. The advantage is that you could move to ISO or anything >else by changing the lower layers, and the application would not be >affected. I get the impression this is the reason they made that >recommendation. Don't think you can move to OSI by just "changing a few layers". There is a lot of layer specific information crossing layer boundaries so if you view RPC as session and XDR as presentation layer there is a lot the be changed. You should read the last part of M.T. Rose's The Open Book on this subject. Sun's RPC isn't the only RPC mechanisme in the world. See the current ACM SIGOP issue for a comparison of about 10 of them. Sun has the advantage that all the NFS implementers had to use SUN RPC to be interconnectable. And when it's there why not use it for other things as well??? But this doen't mean it has been chosen by the network community as being the best possible interface for writing client/server software. (for those who think SUN invented remote procedure calls, it was there before SUN was born, developed, as many amazing things, by XEROX PARC) I hate to say it, but if you want a really safe bet, use sockets. Every system will have a socket libary hanging around for the next ten years. Werner H.P. Vogels Software Expertise Centrum Haagse Hogeschool, Intersector Informatica tel: +31 70 618419 Louis Couperusplein 2-19, 2514 HP Den Haag E-mail: werner@nikhefk.nikhef.nl The Netherlands or werner@hhinsi.uucp
hedrick@athos.rutgers.edu (Charles Hedrick) (08/28/90)
Your complaint about SunNet has nothing to do with the portability or lack thereof of RPC. RPC -- whatever Sun may say -- is not an alternative to streams or sockets. Streams and sockets are ways of accessing the IP or TCP level directly. RPC imposes on top of that a data encoding standard and some other communications standards. It's roughly comparable to ASN.1 plus a bit of mechanism to identify applications. I certainly agree with your complaint that Sun should have implemented host monitoring using SNMP, but not because of any unportability in RPC. RPC is at least as portable as ASN.1. Indeed at the time the SNMP standard was issued, Sun had already posted RPC to the net, and everybody had to write ASN.1 parsers in order to implement SNMP. So SNMP would have been more portable if it had been written using RPC. But it wasn't. So the problem with rolling your own network monitoring protocol on top of RPC isn't that RPC is unportable, but that you're rolling your own network monitoring protocol when there already exists a standard one. At any rate, it seems clear that the advice to use RPC is for people who are writing their own applications. Nobody claims that RPC is going to replace raw TCP for implementing FTP. Give me a break. The claim is that if you want to write a high-level application, RPC handles issues of data portability between different architectures (byte order, floating point format, etc.), and will allow you to move between TCP/IP and ISO when RPC is implemented over ISO. That still seems reasonable advice. However RPC is not unique in this. There are competing mechanisms at the same. Since one of the primary goals of the industry groups is to make sure that Sun doesn't ever repeat their success with NFS, you can be sure hell will freeze over before OSF or anyone else adopts RPC. But at the moment there is specific alternative with overwhelming support. Since NFS is so widely available, and having NFS means that you have to have RPC, that seems to guarantee wide support for RPC. Thus until the industry converges on a single alternative, RPC seems a reasonable choice. Of course this doesn't address the original question, which is whether to use sockets or streams to access TCP. I'm going to do that in a separate response.
root@bvsatl.UUCP (Super user) (08/28/90)
Any obituaries for the sockets programming interface are a bit premature. I admit that for many systems, Streams are preferable to sockets. However most streams based systems also layer a sockets interface on top of the "native" streams. "Why is this?", you may ask. How many public domain programs do you see using the sockets interface? How many do you see using the streams interface? People who want to make their jobs easier will try to build upon the existing code base. Much of that code base written to run on sockets. In addition to the inertia of all that existing code, some systems only support the sockets interface. For instance, many embedded systems are fairly lean implementations that do not include a streams implementation. I would bet that most routers, terminal servers, etc are built on sockets interfaces. If you had to add a new capability (like SNMP for instance) to such a device, you would use the existing services. There are a lot of weird devices now supporting TCP/IP. For instance, I just worked on a implementation team that ported TCP/IP (and sockets) to HP BASIC workstations, believe that or not. It was difficult enough to make a usable BASIC->sockets interface. Streams for basic would be incredibly weird. In order to bring a large number of diverse systems into the internet fold, there must be a least common denominator. Right now, sockets appears to be the least common demoninator. It is not pretty, but it works. Besides, the awkward style provides a certain amount of job security (8-)). Bill VerSteeg Network Research Corp bvs@nrc.com -- Bill VerSteeg internet bvs@nrc.com UUCP gatech.edu!galbp!bagend!bvsatl!bvs
melohn@mrbill.Eng.Sun.COM (Bill Melohn) (08/28/90)
>In article <9008242107.AA19843@ucbvax.Berkeley.EDU>, JAZBO@BROWNVM.BROWN.EDU >("James H. Coombs") writes: > > Sun now states that no new applications should be developed at the socket > level. They recommend 1) RPC or 2) TIL(?--which starts with SunOS 4.1). RPC > has several advantages: If this is stated in any Sun documentation or sales literature, it is in error. Sun Microsystems supports both the sockets and TLI network programming interfaces, as well as Sun RPC. In our SunOS 4.1 release TLI is implemented as a "compatiblity module" to the native socket implementation. In SVR4, sockets are implemented as a "compatiblity module" within the streams framework. All Internet services in both implementations are written using the socket interface.
stanonik@NPRDC.NAVY.MIL (Ron Stanonik) (08/28/90)
> Dear Dan, > You seem to understand these things, so maybe you can help me > with a little semantic problem. Every time I feed a .x file to rpcgen, > it insists on spitting out client and server stubs, which I find > convenient for building my distributed applications. Yet you say that > RPC wasn't designed for client-server applications. I'm confused... RPC seems suitable for networking your application if your application can be implemented using function call/return. It doesn't seem suitable for networking your application if your application simply blasts a variable (and perhaps voluble) amount of text to the user's screen (or into a file). The non-network implementation of such usually consists of write/puts/printf to stdout, but RPC doesn't seem to contain a stream type, such that you keep reading from it until EOF. Ron Stanonik stanonik@nprdc.navy.mil
barmar@think.com (Barry Margolin) (08/29/90)
In article <725@exodus.Eng.Sun.COM> melohn@mrbill.Eng.Sun.COM (Bill Melohn) writes: >>In article <9008242107.AA19843@ucbvax.Berkeley.EDU>, JAZBO@BROWNVM.BROWN.EDU >>("James H. Coombs") writes: >> Sun now states that no new applications should be developed at the socket >> level. >If this is stated in any Sun documentation or sales literature, it is >in error. It's stated in *boldface* at the beginnings of chapters 10 and 11 of the SunOS 4.1 Network Programming Guide: WARNING: Socket-based interprocess communication (IPC), while still supported, is no longer the preferred framework for transport-level programming.... If you are building a new network application that requires direct access to transport facilities, use the TLI mechanisms.... New programs should not be based on sockets. Are you saying that Sun does not actually suggest that TLI be preferred over sockets for new programs? Of course, if a program is intended to be portable to other systems that only have sockets then Sun's recommendation should be ignored. And Sun will have to continue to support sockets for the foreseeable future, so such programs will also be portable to SunOS. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
melohn@mrbill.Eng.Sun.COM (Bill Melohn) (08/29/90)
In article <1990Aug28.212241.10099@Think.COM> barmar@think.com (Barry Margolin) writes: >Are you saying that Sun does not actually suggest that TLI be preferred >over sockets for new programs? Yes. Sun makes no official recommendation as to whether users should use the socket or TLI method of accessing the network. Both are fully supported in SunOS, and both have useful features, as does the RPC method. In fact, we use all three methods in various peices of the utilities bundled with the operating system. A bug report has now been filed on the warning message at the beginning of Chapter 10 and 11 in the Network Programmers Guide.
guy@auspex.auspex.com (Guy Harris) (08/30/90)
>RPC seems suitable for networking your application if your application >can be implemented using function call/return. It doesn't seem suitable >for networking your application if your application simply blasts a variable >(and perhaps voluble) amount of text to the user's screen (or into a file). Actually, there is an application I use that uses RPC to blast variable amounts of text into a file; it's the UNIX copy program. Since my machine is diskless, any such copies go over NFS, which runs atop RPC.... This does, of course, involve more than just the RPC code; it also involves code that sits atop RPC, including code that turns "read()"s and "write()"s into the NFS requests sent over RPC. As such, you might have to write similar stuff yourself if you were to use RPC for bulk data transport in your application, and it wouldn't plug into "read" and "write" in most UNIX systems without some work.
guy@auspex.auspex.com (Guy Harris) (08/30/90)
>Are you saying that Sun does not actually suggest that TLI be preferred >over sockets for new programs? I suspect what he's saying that that different people within Sun say different things, and that he doesn't agree with the authors of those statments in chapters 10 and 11. Which of those people speak for Sun, if any, is a different matter. (Sun is sufficiently large that it's not clear the statement "Sun says XXX" is necessarily meaningful; even if one particular Sun document says "do XXX", that may not mean it's official corporate policy.) >Of course, if a program is intended to be portable to other systems that >only have sockets then Sun's recommendation should be ignored. And Sun >will have to continue to support sockets for the foreseeable future, so >such programs will also be portable to SunOS. And S5R4 has a sockets interface, at least for TCP/UDP/IP (given that Berkeley has, I think, modified the sockets interface for ISO - just as AT&T had to modify the STREAMS/TLI interface for TCP, by putting in the notion of an "urgent mark" - I don't know whether, even if you can use the sockets library to talk to other protocols, you would do so in the same way you did under 4.3-Reno or 4.4BSD). And then you can look forward to POSIX's networking interfaces; I don't know if either of them (DNI in particular) will look like sockets, STREAMS+TLI, or none of the above....
davis@groucho.ucar.edu (Glenn P. Davis) (08/31/90)
In <9008281330.AA00189@atlantic.nprdc.navy.mil> stanonik@NPRDC.NAVY.MIL (Ron Stanonik) writes: >RPC seems suitable for networking your application if your application >can be implemented using function call/return. It doesn't seem suitable >for networking your application if your application simply blasts a variable >(and perhaps voluble) amount of text to the user's screen (or into a file). >The non-network implementation of such usually consists of write/puts/printf >to stdout, but RPC doesn't seem to contain a stream type, such that you keep >reading from it until EOF. >Ron Stanonik >stanonik@nprdc.navy.mil Sun RPC includes a provision for 'batched' rpc's. The procedure call doesn't wait for a return. We have an set of applications based on Sun RPC which use this to "blast variable and voluble amounts of data at a server. Glenn P. Davis UCAR / Unidata PO Box 3000 1685 38th St. Boulder, CO 80307-3000 Boulder, CO 80301 (303) 497 8643
wunder@HP-SES.SDE.HP.COM (Walter Underwood) (09/01/90)
>The non-network implementation of such usually consists of write/puts/printf >to stdout, but RPC doesn't seem to contain a stream type, such that you keep >reading from it until EOF. NCS 2.0 has exactly that feature -- indeterminate-length streams of typed data. OSF cites that as one of the reasons for adopting NCS 2.0 in the the OSF Distributed Computing Environment. See the OSF DCE Rationale. wunder