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
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.