scott@thirdi.UUCP (Scott Southard) (02/04/89)
I've been living (quite happily) in a 4.[23] world in the last few years and have enjoyed the relative ease with which I've been able to write networking code. Now I'm working on a product which wants to run on System V as well as Berkeley systems, and I'm not sure how to go about writing inter-machine networking code. As far as I can tell, the library routines listed in section 3N of the SysV manual (the t_* routines) are vaporware. Is there any portable way to do inter-machine communication on System V? Does the STREAMS interface currently support any networking protocols at all? Any information on how others have dealt with this would be much appreciated. Thanks. -- Scott Southard Third Eye Software pyramid!thirdi!scott Disclaimer: My boss is weirder than I am; what does he care what I think?
ekrell@hector.UUCP (Eduardo Krell) (02/05/89)
In article <446@thirdi.UUCP> scott@thirdi.UUCP (Scott Southard) writes: >Does the STREAMS interface currently support any networking >protocols at all? I'm not sure what your question is. STREAMS is a set of mechanisms and abstractions on top of which you can implement networking protocols such as TCP/IP, X.25, OSI, etc. The Transport Level Interface (TLI) library (The t_* routines you mention) provides a higher level interface to STREAMS, at the OSI Transport level. A couple of vendors have implemented TCP/IP, X.25 and other protocols on top of TLI, but all you get with SVR3.x is STREAMS and TLI. You most likely want a higher level protocol than TLI provides, so you either write your own or, if you like TCP/IP, buy a TCP/IP driver. 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 ) (02/05/89)
In article <11181@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >You most likely want a higher level protocol than TLI provides, so >you either write your own or, if you like TCP/IP, buy a TCP/IP driver. Another approach is to exploit the work someone else has already done to provide reliable high-level protocols (e.g. file transfer or remote execution), by executing a slave process such as "remsh" to take care of all the networking details. Such code is FAR more portable than code that does its own detailed connection handling, etc., and it is general enough to deal with both AT&T and BSD styles of networking, so one can for example have the application connect to whatever system is desired simply by using a data table that gives the appropriate rexec command to use for each host. There is no loss of efficiency either, assuming a reasonable implementation, because one gets back stream FDs just the same as if one had done all the work the hard way.
les@chinet.chi.il.us (Leslie Mikesell) (02/06/89)
In article <9598@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Another approach is to exploit the work someone else has already done >to provide reliable high-level protocols (e.g. file transfer or remote >execution), by executing a slave process such as "remsh" to take care >of all the networking details. Does something like this exist for sysV (P.D., that is), and if so where can it be found? Also, does something like that provide separate stdout/stderr streams back to the calling program? Les Mikesell
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/07/89)
In article <7645@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <9598@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>Another approach is to exploit the work someone else has already done >>to provide reliable high-level protocols (e.g. file transfer or remote >>execution), by executing a slave process such as "remsh" to take care >>of all the networking details. >Does something like this exist for sysV (P.D., that is), and if so where >can it be found? Also, does something like that provide separate >stdout/stderr streams back to the calling program? It would provide whatever the underlying command used for stdout/stderr. If they're coupled together (really stupid, but unfortunately likely), then they would stay that way. Actually if the far end (slave) and near end (master) share a suitable protocol you can use channelized packets to multiplex/demultiplex the streams, but that's getting a bit more complex than what I had in mind. We are actually using the scheme I described for a large software system currently in the final stages of development. The software will be available pretty much for the asking (to U.S. sites), but there are a lot of support packages used by the interprocess communication package, so you have to buy into a lot of our code if you want to use this, or else modify it to suit your tastes. Does anyone know for sure which of the following common utilities can pass 8-bit data fully transparently? rsh rexec remsh
guy@auspex.UUCP (Guy Harris) (02/08/89)
>Does anyone know for sure which of the following common utilities can >pass 8-bit data fully transparently? > rsh rexec remsh "remsh" is, I think, just the name given to "rsh" on some System V implementations to avoid collisions with the restricted shell. "rsh", at least on SunOS 4.0, handled 8-bit data quite happily with the command rsh <machine> "cat >file" <file-with-8-bit-characters i.e., "file" ended up containing the same 8-bit characters, and with the command rsh <machine> "cat file-with-8-bit-characters" >file I didn't find any 177, 200, 0[xX]7[Ff], or 0[xX]80 in the source to the "rsh" or "rexec" daemons, or to the source to the client library routines in 4.3BSD, so I'm not at all surprised to find that it worked OK. (The SunOS 4.0 versions are not heavily modified from the 4.3BSD versions, at least not in parts other than the startup part; I know nobody explicitly 8-bit-cleaned them.) Note that they do invoke a shell to run the command, though - as I remember, it's the login shell of the remote user - so if the shell in question can't handle 8-bit characters, you may have trouble with e.g. command-line arguments.
daveb@gonzo.UUCP (Dave Brower) (02/08/89)
In <11181@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >In article <446@thirdi.UUCP> scott@thirdi.UUCP (Scott Southard) writes: > >>Does the STREAMS interface currently support any networking >>protocols at all? > >I'm not sure what your question is. STREAMS is a set of mechanisms >and abstractions on top of which you can implement networking >protocols such as TCP/IP, X.25, OSI, etc. > >The Transport Level Interface (TLI) library (The t_* routines you mention) >provides a higher level interface to STREAMS, at the OSI Transport >level. >A couple of vendors have implemented TCP/IP, X.25 and other protocols >on top of TLI, but all you get with SVR3.x is STREAMS and TLI. One of the things I *really* like if the Network Programmer's Guide that comes with SVR3, which prominantly features a streams device /dev/tivc in the example code. Unfortunately, such a device does not in fact exist. This means you can't even write toy TLI programs without adding your own drivers. (Actually, a /dev/spx "stream pipe" sometimes exists, but it is undocumented and unsupported, I think. It also isn't bidirectional, which is annoying). Does anyone have have stream driver for bidirectional local connections they'd like to submit to comp.sources.unix? -dB -- If life was like the movies, the music would match the picture. {sun,mtxinu,hoptoad}!rtech!gonzo!daveb daveb@gonzo.uucp
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/09/89)
In article <501@gonzo.UUCP> daveb@gonzo.UUCP (Dave Brower) writes: >(Actually, a /dev/spx "stream pipe" sometimes exists, but it is >undocumented and unsupported, I think. It also isn't bidirectional, >which is annoying). I thought it was supposed to be full-duplex; it certainly SHOULD be. In my opinion, normal pipes should be full-duplex streams. To heck with the FIFO compatibility argument. This could have been fixed with the release of SVR3, but "compatibility" caused pipes to remain kludgy.
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (02/09/89)
In article <501@gonzo.UUCP>, daveb@gonzo.UUCP (Dave Brower) writes: > (Actually, a /dev/spx "stream pipe" sometimes exists, but it is > undocumented and unsupported, I think. It also isn't bidirectional, > which is annoying). Yes it is bidirectional; however, it's only a half-pipe. More precisely, to create a stream pipe one has to open /dev/spx twice, and issue the I_FDINSERT on one file descriptor passing down the value of the second file descriptor. (Don't blame me, folks; I didn't invent /dev/spx or the ioctl.) In the distributed system, /dev/spx is mode 644, I believe; it's certainly not 666. I cannot vouch for the security of a system in which /dev/spx is made generally available; its primary (sole?) purpose is to support parts of RFS, and it's quite possible that the security of RFS could be compromised by such a change. On the other hand, I don't know that such a scenario is possible; I've never felt the urge to dig that deeply into RFS internals.
les@chinet.chi.il.us (Leslie Mikesell) (02/09/89)
In article <9605@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: [re: remsh/rsh] >It would provide whatever the underlying command used for stdout/stderr. >If they're coupled together (really stupid, but unfortunately likely), >then they would stay that way. Actually if the far end (slave) and near >end (master) share a suitable protocol you can use channelized packets to >multiplex/demultiplex the streams, but that's getting a bit more complex >than what I had in mind. Would you multiplex a single stream in user code otherwise or open two virtual circuits? Does this require a process per stream at the remote end? What about file descriptors > 2? Les Mikesell
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/10/89)
In article <7666@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Would you multiplex a single stream in user code otherwise or open >two virtual circuits? Does this require a process per stream at the >remote end? What about file descriptors > 2? As I said, at that point it's getting more complex than I would recommend dealing with in user mode. In fact, a lot of this stuff cannot be done properly without cooperation of the system object allocator (e.g. UNIX kernel). In fact, most existing UNIX implementations can't do it right without really radical kernel modification! Streams provide the foundation for doing a good job of this, but the original discussion was about portable approaches. Streams are unfortunately not universal, and OSF seems determined to keep it that way. User-mode multiplexing is not unheard of; it's how our Blit-descendant terminals operate in layers mode on 4BSD-based systems. But context switch overhead is excessive. If you have multiple virtual circuit capability, use it. Somewhere in the underlying implementation there will very likely be code that multiplexes the circuits onto a single physical link anyway. The idea is to take advantage of the work that somebody else has already invested in figuring out the optimal way to implement such things, rather than doing it yourself.