kp@hjuxa.UUCP (Karen Paszamant) (07/20/87)
Does anyone know what vendors have a System V Release 3.0 streams based tcp/ip product? The only vendors I have found so far are Lachman Assoc. & Wollongong. There must be others. Thanks, in advance
mel1@houxa.UUCP (M.HAAS) (07/21/87)
Would someone please post a summary of reasons why use of Streams is
an advantage. Is this just another sales-hype buzzword? or is there
a reason Streams is better? than sockets? than psudo-sockets? or
select? Does the end user see any advantage? faster response? less
CPU waste? what? Does anyone have some before & after figures on
drivers that were converted to Streams? Please share them with us.
Thanks,
Mel Haas , odyssey!melespo@bpa.BELL-ATL.COM (Bob Esposito) (07/22/87)
In article <725@hjuxa.UUCP> kp@hjuxa.UUCP (Karen Paszamant) writes: > >Does anyone know what vendors have a System V Release 3.0 >streams based tcp/ip product? The only vendors I have found >so far are Lachman Assoc. & Wollongong. There must be others. > >Thanks, in advance Uniq Digital Technologies in Batavia, IL. does have a Streams based TCP/IP product for System V Release 3.0 They advertise being the leading supplier for AT&T System V.3 with RFS for Digital Equipment Corp. processors. -- ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=== Bob Esposito, Bell of Pennsylvania - espo@bpa.bell-atl.com - (215) 466-6831 ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===
news@uniq.UUCP (Usenet Administration) (07/22/87)
In article <725@hjuxa.UUCP>, kp@hjuxa.UUCP (Karen Paszamant) writes: > Does anyone know what vendors have a System V Release 3.0 > streams based tcp/ip product? Uniq Digital Technologies supports UNIX System V Release 3 TCP/IP for VAX processors. The product, called Passage, is available in binary or source form. The next release of Passage will be Streams based. That release is expected within approximately 30 days. Contact Trish Halleen on 1-800-DEC-UNIX for more information about Passage or Uniq's port of System V Release 3 to VAX processors. -- Uniq Digital Technologies 28 South Water Street Batavia, Illinois 60510
monkey@unixprt.UUCP (Monkey Face@unixprt) (07/23/87)
In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes: > Would someone please post a summary of reasons why use of Streams is > an advantage... is there a reason Streams is better? than sockets?... > Does the end user see any advantage?... > Thanks, > Mel Haas , odyssey!mel First it is STREAMS, as apposed to Streams, streams, this differenciates it from a stream based environment. The primary advantage, for those using ATT based UNIX, is that this is the only 'real' facility provided in UNIX System V to support networking. It basically provides the 'structure' that allows layered protocols a consistent interface to other layers in a somewhat independent manner. It is not necessarily 'better', but it is a more appropriately structure for the varying protocols than other implementations (such as the 4.x BSD architecture). Hopefully the 'end-user' doesn't get involved at this level. ATT's Transport Interface is mostly base on the ISO transport interface, therefore should map to the emerging interface standards. I have found that performance is not considerably different in s STREAMS based vs. 4.x BSD based implemetnation of TCP/IP. Monkey Face - uni-xperts
bob%tut.cis.ohio-state.edu@osu-eddie.UUCP (Bob Sutterfield) (07/23/87)
In article <314@uniq.UUCP> news@uniq.UUCP (Usenet Administration) writes: >In article <725@hjuxa.UUCP>, kp@hjuxa.UUCP (Karen Paszamant) writes: >> Does anyone know what vendors have a System V Release 3.0 >> streams based tcp/ip product? >Uniq Digital Technologies supports UNIX System V Release 3 TCP/IP for >VAX processors. ... Contact Trish Halleen on 1-800-DEC-UNIX ... I just did. I was about the dozenth person who had inquired whether they do IP on 3B2s under SVr3 too (which they don't), and whether they planned to (ditto). *Disappointment*. I guess I'm stuck with TWG. -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@ohio-state.{arpa,csnet} or ...!cbosgd!osu-eddie!bob soon: bob@aargh.cis.ohio-state.edu
guy%gorodish@Sun.COM (Guy Harris) (07/23/87)
> The primary advantage, for those using ATT based UNIX, is that this is the > only 'real' facility provided in UNIX System V to support networking. Gee, for some time now the people at Berkeley have been using an "AT&T-based UNIX" (the only non-"AT&T-based" UNIXes I know of are things like Mark Williams' "Coherent", which was written from scratch) that supports networking without STREAMS. Plenty of other people have dropped the socket code into System V kernels, just as Berkeley dropped it into a 32V-derived kernel, so STREAMS are not "the only game in town". > ATT's Transport Interface is mostly base on the ISO transport interface, > therefore should map to the emerging interface standards. Unfortunately, the TLI also has a number of warts, such as the fact that it keeps some state both in userland and in the kernel, so that after a "fork"/"exec" you have to issue a "t_sync" call to pull the kernel's notion of the state into userland. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
mark@applix.UUCP (Mark Fox) (07/24/87)
In article <278@unixprt.UUCP> monkey@unixprt.UUCP (Monkey Face@unixprt) writes: >In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes: >> Would someone please post a summary of reasons why use of Streams is >> an advantage... is there a reason Streams is better? than sockets?... >> Does the end user see any advantage?... > >The primary advantage, for those using ATT based UNIX, is that this is the >only 'real' facility provided in UNIX System V to support networking. Possible, but have you seen HP's or CPC's implementation of sockets in their System V ports? Looks plenty "real" to me and cleanly done as well. >It is not necessarily 'better', but it is a more appropriately structure >for the varying protocols than other implementations (such as the >4.x BSD architecture). What do you mean by "a more appropriate[ly] structure"? Could you back this up or is this only an opinion? >Hopefully the 'end-user' doesn't get involved >at this level. But with 4.x all the end-user needs to know is a host name in order to use the Berkeley "r" utilities assuming NFS across remote mount points is not being used instead. >ATT's Transport Interface is mostly base on the ISO >transport interface, therefore should map to the emerging interface >standards. But its easy enough to add new socket types as Sun has for its OSI protocol implementation. >I have found that performance is not considerably >different in s STREAMS based vs. 4.x BSD based implemetnation of TCP/IP. So? >Monkey Face - uni-xperts What're those? Don't get me wrong - I'm not a socket bigot - but I have never seen an implementation of streams and I am still curious why some people prefer them. -- Mark Fox Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300 uucp: seismo!harvard!m2c!applix!mark
daveb@geac.UUCP (Dave Brown) (07/24/87)
In article <561@applix.UUCP> mark@applix.UUCP (Mark Fox) writes: >>In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes: >>> Would someone please post a summary of reasons why use of Streams is >>> an advantage... is there a reason Streams is better? than sockets?... >>> Does the end user see any advantage?... >... >Don't get me wrong - I'm not a socket bigot - but I have never seen an >implementation of streams and I am still curious why some people prefer them. There is interest in streams for several reasons. 1) It looks elegant. 2) It comes from an acknowleged Unix expert. 3) It *looks* (emphais added) more general than sockets. 4) It allows a structured decomposition of some of the hot-spots in Unix (terminal handling, protocols) into subparts which can be placed on a front-end processor. There is use of streams for other reasons. 1) Bell provides it instead of sockets. 2) Some customers will buy anthing that Berkley *doesn't* make. 3) Some system/hardware designers want (4) above. 4) Some system/hardware designers have fallen in love with any of the above. Personally, I like (4), having worked on a machine which used FEPs effectively (as well as two which didn't, all from the same manufacturer!). --dave (unix hack on a 'bun) collier-brown -- David (Collier-) Brown. | Computer Science Geac Computers International Inc., | loses its memory 350 Steelcase Road,Markham, Ontario, | (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
rwhite@nu3b2.UUCP (Robert C. White Jr.) (07/25/87)
This is a semi-informed retelling... As I understand it, STREAMS is/are intelegent filter devices. As such some of the filters can be "multiplexing". You can "open" a "stream head" to a multiplexing STREAMS module and then connect a potentally infinite number of other STREAMS and still only have one "open" counting against your allowed maximum. Since all files are STREAMS you can pass whole file descriptors between processes through an IOCTL call [FD_GIVE and FD_RCV or somesuch]. The flexability is very interesting, and seems to allow recursive nesting of STREAMS modules such that you decide which "layer" you wish to work with depending what stream head you open. i.e. Starlan support for the 3B2 [from program level] requires you use a strange set of primitives to establish the link [they are all in a library] but after you have the link you ay "push" a module on the stream which makes read, write, putsg, and getmsg the [only] valid primitives against the stream. [you can't use read etc. while you are useing the deeper t_primitive calls] What this means is, you can open a connection accross a/the network then "push" the module and pipe the connection through any normal means. when the subtask/pipe exits you pop the module off the stream and terminate the connection. It all looks very interesting, I am watching this stuff carefully, but I havn't been able to upgrade my OS yet so I don't know how well it works first hand. Robert. Disclaimer: My mind is so fragmented by random excursions into a wilderness of abstractions and incipient ideas that the practical purposes of the moment are often submerged in my consciousness and I don't know what I'm doing. [my employers certainly have no idea]
monkey@unixprt.UUCP (Monkey Face@unixprt) (07/28/87)
I'm not sure that this is worth it, but what the heck... In article <24072@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > > The primary advantage, for those using ATT based UNIX, is that this is the > > only 'real' facility provided in UNIX System V to support networking. > Gee...people at Berkeley have been using an "AT&T-based UNIX"... > that supports networking without STREAMS. Plenty of other > people have dropped the socket code into System V kernels... > Berkeley dropped it into a 32V-derived kernel, so STREAMS are not > "the only game in town". I only meant that STREAMS is what you get with the current versions from ATT, without the cost of re-porting to each new AT&T release, you don't get sockets or anything else. A vendor that must rely on ATT to provide a base, a strategy based on sockets does not seem appropriate in the long term. > > ATT's Transport Interface is mostly base on the ISO transport interface, > > therefore should map to the emerging interface standards. > Unfortunately, the TLI also has a number of warts...it keeps some state > both in userland and in the kernel...after a "fork"/"exec" you > have to issue a "t_sync" call to...(get)... kernel's...state into userland. > Guy Harris So what? Warts can be removed, if deemed necessary. My response to a question someone asked was not meant to support or criticize STREAMS or the Socket implementation in 4.x based systems. I was only offering my opinion based on experience with STREAMS. I have also ported the socket code the System V version of UNIX and think that sockets are a very good base for network implementation. How tall is Guy Harris anyway? Monkey Face - uni-xperts
guy%gorodish@Sun.COM (Guy Harris) (07/28/87)
I won't bother replying to the whiny little question at the end, but I will point out a couple of things: > I only meant that STREAMS is what you get with the current versions from > ATT, without the cost of re-porting to each new AT&T release, you > don't get sockets or anything else. A vendor that must rely on ATT > to provide a base, a strategy based on sockets does not seem appropriate > in the long term. That depends on several things. First, it depends on whether the vendor wants to continue to depend on AT&T to provide a base, especially given the S5R3 licensing agreement. Second, it depends on whether they want to re-port the rest of what they've done to S5R3. Yes, STREAMS comes "for free" with S5R3. This is not necessarily sufficient to make it the best way to go. Unisoft, I believe, offers a socket implementation as part of their S5 ports. > So what? Warts can be removed, if deemed necessary. It is not necessarily that easy. The TLI uses the state information that is kept in userland; it might have to be redesigned to remove this particular wart. It is not a given that the TLI will be the interface used for future protocol implementations; a socket-based ISO implementation (which may require changes to the socket interface) or some completely different C-language binding of network operations may end up being dominant. > My response to a question someone asked was not meant to support or > criticize STREAMS or the Socket implementation in 4.x based systems. My response wasn't meant to do that either; it was meant to point out the other side of various issues. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy *! AFN"("(".
guy%gorodish@Sun.COM (Guy Harris) (07/28/87)
> There is interest in streams for several reasons. > 1) It looks elegant. However, in practice there are some rather inelegant parts. Doing an "ioctl" on a stream, for example, is a pain in the neck, as a streams module or driver is notified of the "ioctl" by receiving a message, and it must construct a reply message in order to respond to the "ioctl". Since streams modules and drivers do not necessarily run in the context of a process, even when servicing a request made in a process (e.g., a "write" or an "ioctl"), they cannot block; thus, if a memory allocation fails, you have to go through some amount of contortions to retry the allocation if it's important to do so. Were STREAMS to be implemented on top of a kernel that supported "lightweight processes", one could guarantee that streams modules and drivers ran in the context of a thread of control that could safely block, which would considerably simplify this. The read side of a stream is driven by pressure from the bottom; there is little a streams module or driver can do in response to a "read". This may be a problem for some uses of STREAMS. If you want a STREAMS-based terminal driver, there will be some problems with sharing a single pool of buffer resources between the networking code and the terminal driver; it makes it more likely that networking operations will exhaust these resources. (RSX-11 users may remember that - at least in some versions, they may have fixed this later - a process that consumed all of pool space, or just sufficient pool space as to prevent the tty driver from doing a read, could hang the system fairly thoroughly.) This is not an insuperable problem, but it means you have to be careful. When writing a streams module or driver, there is often a lot of "bureaucratic" code that has to be added to handle various message types, to construct messages, etc.; don't assume things are going to get smaller if you go to STREAMS. > 2) It comes from an acknowleged Unix expert. The concept is the same in Dennis Ritchie's version and in the S5R3 version, but some of the details are different. I believe the S5R3 version is bigger and more complicated. > 3) It *looks* (emphais added) more general than sockets. Since it imposes less structure, it is. Sockets correspond roughly to streams+TLI. > 4) It allows a structured decomposition of some of the > hot-spots in Unix (terminal handling, protocols) > into subparts which can be placed on a front-end > processor. Probably true, although this depends on what the streams modules that implement a given function are. It may be that the decomposition that makes the most architectural sense isn't the decomposition that makes sense for a particular front-end processor. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
peter@xios.XIOS.UUCP (Peter Manson) (07/29/87)
In article <725@hjuxa.UUCP> kp@hjuxa.UUCP (Karen Paszamant) writes: > >what vendors have a System V Release 3.0 streams based tcp/ip product? > At a special session on STREAMS TCP/IP at the March TCP/IP Interoperability Conference, the following vendors were on the panel (so they're at least working on it): Convergent Technologies / Lachmann Associates Excelan The Wollongong Group Counterpoint Interactive Systems Sorry, I don't have addresses, etc. for them. -- Hope this helps.
paul@whuts.UUCP (HO) (07/29/87)
In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes: > Would someone please post a summary of reasons why use of Streams is > an advantage. Is this just another sales-hype buzzword? or is there > a reason Streams is better? than sockets? than psudo-sockets? or > select? Does the end user see any advantage? faster response? less > CPU waste? what? Does anyone have some before & after figures on > drivers that were converted to Streams? Please share them with us. Chapter 10 of the Bach book (The Design of the UNIX Operating System) has a pretty good discussion and description on STREAMS. Also, Bach and others have also written some papers on the SVR3 STREAMS implementation, which differs slightly from the Research STREAMS. Paul Ho
monkey@unixprt.UUCP (Monkey Face@unixprt) (07/31/87)
In article <24335@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > I won't bother replying to the whiny little question at the end,... Two n's in 'whinny', besides I was laughing at the time. Several people at Sun have mailed me the answer anyway. Anyone who wants to know can ask me via mail. > > ...A vendor that must rely on ATT > > to provide a base, a strategy based on sockets does not seem appropriate > > in the long term. > That depends on several things. First, it depends on whether the > vendor wants to continue to depend on AT&T to provide a base, especially > given the S5R3 licensing agreement. Second, it depends on whether > they want to re-port the rest of what they've done to S5R3. Most current and near future UNIX vendors do and will use S5Rn based ports. I beleive that vendor management can see the costs associated with not following this path. Their customer will demand upward compatible functionality.
gwl@rruxa.UUCP (George W. Leach) (08/03/87)
In article <24336@sun.uucp>, guy@gorodish.UUCP writes: > > The concept is the same in Dennis Ritchie's version and in the S5R3 > version, but some of the details are different. I believe the S5R3 > version is bigger and more complicated. > I beleive that I have seen a socket interface built on top of streams in 8th Edition UNIX. Has anyone else? Also, has anyone noticed if the interface to stream i/o has changed between the 8th Edition and System V implementations? George W. Leach Bell Communications Research New Jersey Institute of Technology 444 Hoes Lane 4A-1129 Computer & Information Sciences Dept. Piscataway, New Jersey 08854 Newark, New Jersey 07102 (201) 699-8639 UUCP: ..!bellcore!indra!reggie ARPA: reggie%njit-eies.MAILNET@MIT-MULTICS.ARPA From there to here, from here to there, funny things are everywhere Dr. Seuss "One fish two fish red fish blue fish"
rees@apollo.uucp (Jim Rees) (08/06/87)
First, this is probably obvious, but "sockets" is an interface, and is best
compared to TLI. Streams is an implementation framework, and has no direct
counterpart in bsd4.3, although it was originally intended as a replacement
for clists and parts of tty.c.
I'm doing a streams implementation here (see my paper in the Phoenix Usenix
Proceedings). It has a TLI interface and a socket interface too. The two
don't always cooperate very well, but it sort of works. 8th edition has
a socket interface too, but I haven't seen it and don't know how it works.
Guy Harris:
If you want a STREAMS-based terminal driver, there will be some
problems with sharing a single pool of buffer resources between the
networking code and the terminal driver; it makes it more likely that
networking operations will exhaust these resources.
SysV neatly avoids this problem by not using streams for ttys! There
is a simple priority scheme that tries to avoid this problem, but it
isn't really adequate, especially since the guy (no relation to Guy)
who wrote the tty driver probably didn't talk to the guy who wrote the
IP multiplexor about who was going to allocate how much of which priority.
The concept is the same in Dennis Ritchie's version and in the S5R3
version, but some of the details are different. I believe the S5R3
version is bigger and more complicated.
AT&T added multiplexors (I believe), which are really necessary for
doing protocols. They also added the clone driver, a crock if I've ever
seen one. My version of this uses a special minor device number to
indicate a clone open, and there is no separate clone driver. The sysV
version of streams is indeed bigger and hairier than the v8.
The big potential advantage to streams, from my point of view, is that
it allows you to mix and match protocol modules. Want to run TCP on top
of X.25 transport? Buy a TCP multiplexor module from vendor A, a X.25
network multiplexor from vendor B, and a driver from vendor C. Plug them
all in and it just works. In practice, this requires everyone to use
the same messsages between all their modules, and the interconnectivity
problems make the TCP/IP interoperability problems we are all so painfully
aware of look as easy as tying your shoes in comparison.martin@felix.UUCP (Martin McKendry) (08/07/87)
In article <24336@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: > >Since streams modules and drivers do not necessarily run in the >context of a process, even when servicing a request made in a process >(e.g., a "write" or an "ioctl"), they cannot block; thus, if a memory >allocation fails, you have to go through some amount of contortions >to retry the allocation if it's important to do so. Were STREAMS to >be implemented on top of a kernel that supported "lightweight >processes", one could guarantee that streams modules and drivers ran >in the context of a thread of control that could safely block, which >would considerably simplify this. We are considering using streams as a basis for some future work on our distributed file system, as well as for networking. The problem Guy cites above, inability to block on resources, seems to be a MAJOR one. The code I have seen seems to do mutual exclusion via spl, which is pretty crude but works. I guess we could do that, but often we need to block to read from disk, or to get long-held resources, such as inodes. So what work-arounds exist? I cannot believe that real software has been implemented with streams without this problem coming up. Any experience or suggestions? Or are the applications implemented so far sufficiently simple that this is not a problem? In which case, Streams are maybe half of a message handling mechanism, which is probably worse than none at all. Sadly. -- Martin S. McKendry FileNet Corp {hplabs,trwrb}!felix!martin
guy%gorodish@Sun.COM (Guy Harris) (08/07/87)
> We are considering using streams as a basis for some future work on > our distributed file system, as well as for networking. The problem > Guy cites above, inability to block on resources, seems to be a > MAJOR one. Nope. AT&T's RFS uses STREAMS to talk to the transport layer it uses, so there is an existence proof. The secret is that the AT&T RFS (or NFS, or probably Todd Brunhoff's RFS) server is implemented as a separate UNIX process; the server code runs in the context of that process (or processes, if you have more than one server). *That* process can block waiting for a disk, or other resource, if it wants to. The client code probably also runs in the context of a UNIX process; if it's running in the process that makes the request, it obviously is, and NFS has a daemon to handle asynchronous requests. This code can also block if it has to. The trick here is that none of the file system code is implemented as a STREAMS module; that's not really what STREAMS were developed for. However, there may be cases where something that STREAMS *was* developed for, such as a network protocol implementation, would want to block. There are cases, both in the STREAMS framework and the 4BSD sockets/protocols framework, where it can't do this conveniently. The problem with the STREAMS mechanism is that there are *no* places where you can *guarantee* that you can block, if you want to follow the letter of the law. If you "know" that there are no modules with service procedures above you, and you "know" the way put procedures are called, so that you "know" that your module's "put" procedure will be called in the context of the process making the request that causes the message to be sent downstream, you could cheat; however, you can't really "know" any of those things. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com