gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/07/88)
In article <422@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > many styles of networking: SunOS, TCP/IP, BSD sockets, streams; > multiple interfaces: curses, OPEN LOOK, NeWS, X11/NeWS; > more file system types: s5, BSD ufs, nfs, rfs, proc; > more types of inter-process communications: Xenix semaphores, sockets, > Sun RPC, Sys V ipc, named streams. This list doesn't convey an accurate picture, because you have lumped together different kinds of things, making it appear that there are more choices in each category than there actually are. For example, sockets and streams are the two fundamental network connection technologies, and it is even possible that in SVR4 sockets are emulated via streams. The main alternative to so-called "TCP/IP" (really, Internet protocol suite) is OSI. TCP itself is supported on sockets or streams, your choice (I don't know which SVR4 chose; both implementations are known to exist). The main reason for the wide variety is to support as many existing applications as possible. Existing applications were developed to use any of a variety of technologies. It is an expensive hassle to have to change them to use a different technology. Many of these varieties can be layered on a common base, and I expect some of them will gradually fade away as applications are adapted to use the more attractive ones. For example, some might argue that RFS is technically a better UNIX transparent remote file system technology, but NFS is too widespread to ignore, so support for it is necessary. (Also, they aren't quite equivalent. RFS implements full UNIX file system semantics; NFS aims at a more generic level of file system so it includes MS-DOS, for example.) RFS might eventually fade away, but then it might start catching on. > (1) The market might reject Sys V Release 4 as too bulky (not likely, but > possible: this might move people to OSF/AIX), Where you don't even HAVE streams? Seems rather a silly decision. > (4) Software houses might stick with their historical orientation: > BSD shops would only use the features of Rel 4 that are common to BSD, > Xenix shops would stick to the Xenix features, etc. I'm sure that initially there will be this tendency. > An alternative, semi-serious hypothesis: have Ritchie, Thompson, Kernighan, >Plauger, et alii, been secretly working to re-invent Multics all these years > :-) ? No, and they haven't had all that much to do with the commercial UNIX product either. The Bell Labs research UNIX system is considerably less featureful; several of its innovations have made it into the commercial product, but the problem is that existing commercial UNIX features are not being dropped at the same rate, probably because of the perceived need to continue to support existing applications that depend on the old cruft.
ekrell@hector.UUCP (Eduardo Krell) (12/07/88)
In article <9089@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >For example, sockets >and streams are the two fundamental network connection technologies, and >it is even possible that in SVR4 sockets are emulated via streams. Well, to be more precise, sockets and streams are not at the same level of abstraction. Streams are a general mechanism for implementing a wide variety of communication protocols and IPCs. Sockets are a much higher level abstraction and can be implemented in terms of (or on top of) streams. This is how SVR4 will do it. I don't know what you mean by sockets being "emulated via streams". You can provide a socket library to present the same interface as the socket related system calls in BSD. The point is that they don't need be in the kernel anymore. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/07/88)
In article <10968@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >I don't know what you mean by sockets being "emulated via streams". >You can provide a socket library to present the same interface as >the socket related system calls in BSD. The point is that they don't >need be in the kernel anymore. Yup, that's what I meant. Glad to hear that in SVR4 sockets won't be implemented separately in the kernel.
guy@auspex.UUCP (Guy Harris) (12/09/88)
>You can provide a socket library to present the same interface as >the socket related system calls in BSD. The point is that they don't >need be in the kernel anymore. Well, err, umm, code to perform much of the *equivalent* of those system calls may end up in the kernel (cf. TPI), so it's not quite so much of an improvement as it seems.
ekrell@hector.UUCP (Eduardo Krell) (12/09/88)
In article <654@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >Well, err, umm, code to perform much of the *equivalent* of those system >calls may end up in the kernel (cf. TPI), so it's not quite so much of >an improvement as it seems. Well, it will be an improvement once you try to add the greatest, latest communication protocol (OSI or whatever) and you realize that you don't need new system calls !! Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
guy@auspex.UUCP (Guy Harris) (12/11/88)
>Well, it will be an improvement once you try to add the greatest, latest >communication protocol (OSI or whatever) and you realize that you don't >need new system calls !! No, instead you need new messages, or some other new functionality, in the TPI interface. (Can you say "urgent pointer"?)
andrew@uel.uel.co.uk (Andrew Josey) (12/15/88)
In article <417@maxim.ERBE.SE>, prc@ERBE.SE (Robert Claeson) writes: > As far as I know, RFS does not use something like XDR. Instead, data is > sent in the particular machine byte order on the network. To paraphrase the System V Porting Rules (for SVR3): In order for RFS to share data and files between heterogeneous machines which have different byte ordering,data alignment etc, data is converted to a canonical format before sending out to the network. The canonical formats used in RFS conform to Sun's External Data Representation (XDR). The decision on whether to use canonical formats is negotiated at virtual circuit set-up time. >Furthermore, RFS is closely tied to the System V 0.5, 1 and 2K block file >systems and cannot be used on BSD file systems. Not even in SVR4 (at least, > that's how I interpreted it). I might be wrong. RFS will work on both s5 filesystems and the ufs filesystem type (an implementation of the BSD "fast filesystem") in SVR4.0. -- Andrew Josey, AT&T Unix Europe, a Division of AT&T (UK) Ltd. International House, Ealing Broadway, London W5 5DB, England, UK uucp:{ mcvax!ukc, attunix} uel!andrew { The usual disclaimer .... }