randy@umn-cs.cs.umn.edu (Randy Orrison) (06/28/88)
For a project I'm working on...
What are the SVID and POSIX eqivalents of sockets in BSD?
What are the standard approaches to a user program using network services
in System V (I guess I'm also interested in pre-SVID versions of SysV) and
under the proposed POSIX standard?
I suppose it would be nice to have a quick summary description too...
Also, do they interface? Can i connect a socket on a BSD system to a snark
on a POSIX system?
Thanks in advance!
-randy
"Reply via mail, if there's interest i'll summarize back to the net."
--
Randy Orrison, Control Data, Arden Hills, MN
randy@ux.acss.umn.edu {bungia, uunet!hi-csc, rutgers, sun}!umn-cs!randy
"I consulted all the sages I could find in Yellow Pages,
but there aren't many of them." -APPmb@ttidca.TTI.COM (Michael Bloom) (06/29/88)
In article <5968@umn-cs.cs.umn.edu> randy@umn-cs.UUCP (Randy Orrison) writes: >For a project I'm working on... > What are the SVID and POSIX eqivalents of sockets in BSD? That's a real good question. For now, SV3 has no *close* equivalents. TCP/IP has been promised for 5.4, but the big (hear this, AT&T?) question is "via what mechanism?" Berkeley recently released a new version of TCP, which SUN has incorporated into SUNOS 4.0 in the same manner as before: Sockets are accessed _in place of_ inodes; not thru, but in place of. You could loosely call the mechanism used "the file descriptor type switch" (f_type and f_ops). In contrast system V networking is done through (tli) library routines which make multiple calls via the inode interface that in turn find their way into the streams code, passing streams messages through multiple modules possibly before even encountering the tcp protocol code. Portions of "the big question are": Will IP/UDP/TCP be rewritten as streams modules? What about the UNIX domain? Alternately, will a stream cap driver be written that provides a tpi interface? If so, perhaps this could co-exist with the current socket level code, to support the vast quantities of existing applications. A question for SUN: Are there plans for 5.4 being able to run binaries compiled to run under SUNOS 4.x? If so, will this result from services provided by SUN's 5.4 being different from those provided by AT&T's 5.4? Will streams itself be different in 5.4? Sun has documented that they had to "extend" streams just to be able to provide a streams terminal driver that could handle the bsd functionality not present in system V tty drivers. Will further "extensions" be necessary (or provided as the new standard) for being able to properly and efficiently support BSD networking? Judging from discussions I've had with people using streams for (non-tcp) networking the answer is probably yes, but it would be useful to hear the official word on this. For future compatibility: Should people *now* writing new protocols that will use IP put stream caps on the bsd protocols? Or should they use the protocol-protocol interface? >Also, do they interface? Can i connect a socket on a BSD system to a snark >on a POSIX system? If you're talking about TCP snarks, you should be able to.
ekrell@hector.UUCP (Eduardo Krell) (07/01/88)
In article <2820@ttidca.TTI.COM> mb@ttidca.tti.com (Michael Bloom) writes: >> What are the SVID and POSIX eqivalents of sockets in BSD? > >That's a real good question. For now, SV3 has no *close* equivalents. There are various third party vendors (like Lachman and Wollongong) who offer the entire TCP/IP suite, including a socket library for SVR3. Some of these implementations are streams-based and some are not. >TCP/IP has been promised for 5.4, but the big (hear this, AT&T?) >question is "via what mechanism?" Streams is the natural mechanism to implement communication protocols in SVR3 and higher. Besides, if you're provided with a socket emulation library, you really don't care what the kernel implementation looks like. >Portions of "the big question are": Will IP/UDP/TCP be rewritten as >streams modules? They've already been rewritten. See above. >Will streams itself be different in 5.4? Sun has documented that they >had to "extend" streams just to be able to provide a streams terminal >driver that could handle the bsd functionality not present in system V >tty drivers. You can add stream modules to support whatever interface you want. I guess Sun wanted to provide a BSD-like tty interface, so they had to write an appropriate stream module to support their ioctl's, etc. I don't see why the streams mechanism itself would have to be changed. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com
guy@gorodish.Sun.COM (Guy Harris) (07/01/88)
> I don't see why the streams mechanism itself would have to be changed.
Can you say "VMIN/VTIME"? I thought you could.... However, you can't say it
on a vanilla S5R3.1 system, at least not if your tty driver is streams-based
(which the S5R3.1 one isn't).gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/01/88)
In article <2820@ttidca.TTI.COM> mb@ttidca.tti.com (Michael Bloom) writes: >Portions of "the big question are": Will IP/UDP/TCP be rewritten as >streams modules? What about the UNIX domain? I thought it had been, by Wollongong over a year ago. >Will streams itself be different in 5.4? Sun has documented that they >had to "extend" streams just to be able to provide a streams terminal >driver that could handle the bsd functionality not present in system V >tty drivers. The only thing I can think of that might need an extension would be adding back the delimiter messages (M_DELIM) that Dennis originally had in his prototype streams implementation. I have been told that these have been added to STREAMS in whatever the latest SVR3 release is.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/02/88)
In article <58603@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >> I don't see why the streams mechanism itself would have to be changed. >Can you say "VMIN/VTIME"? At last, some probably reliable information about this. The funny thing is, the original comment was that STREAMS had to be changed to accommodate features of the BERKELEY terminal handler. It now sounds like it had to be changed for System V itself.
bc@halley.UUCP (Bill Crews) (07/02/88)
In article <2820@ttidca.TTI.COM> mb@ttidca.tti.com (Michael Bloom) writes: >In article <5968@umn-cs.cs.umn.edu> randy@umn-cs.UUCP (Randy Orrison) writes: >>For a project I'm working on... > >> What are the SVID and POSIX eqivalents of sockets in BSD? > >That's a real good question. For now, SV3 has no *close* equivalents. Really? SVID, Issue 2, Volume describes TLI, which is so close to sockets that many wonder why a new facility was introduced. The implementation differs, but that wasn't the question. -- Bill Crews bc@halley.UUCP (512) 244-8350 ..!rutgers!cs.utexas.edu!halley!bc
guy@gorodish.Sun.COM (Guy Harris) (07/02/88)
> The funny thing is, the original comment was that STREAMS had to be > changed to accommodate features of the BERKELEY terminal handler. > It now sounds like it had to be changed for System V itself. It had to be changed for both. It needed to be changed to support System V VMIN/VTIME processing, of course (it's hard for a streams module to implement VMIN = 0, VTIME != 0, since the timer starts when the "read" is done and streams modules don't get told when somebody does a "read"), but it also had to be modified for: 1) job control and 2) some backwards compatibility stuff (support for TIOCGETD and TIOCSETD, which have to be mapped in a somewhat unpleasant fashion into pushes and pops of streams modules) which could be counted as features of the Berkeley terminal handler. (The S5 driver has line disciplines as well; however, since the only one provided with vanilla S5 was the standard one, we didn't bother making "c_line" do anything in the S5-style "ioctl"s.) In addition, it had to be changed to support "select" (building "select" on top of "poll" turns out to be uglier than just implementing "select" for streams, given the way "poll" is implemented), as well as BSD-style no-delay I/O and "asynchronous" I/O. (It also had to be changed for S5-style no-delay I/O, because streams no-delay I/O is basically POSIX-style non-blocking I/O, which resembles BSD-style no-delay I/O.)
djg@sequent.UUCP (Derek Godfrey) (07/05/88)
In article <58603@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) writes: > > I don't see why the streams mechanism itself would have to be changed. > > Can you say "VMIN/VTIME"? I thought you could.... However, you can't say it > on a vanilla S5R3.1 system, at least not if your tty driver is streams-based > (which the S5R3.1 one isn't). This requires a small change in strwrite() and a distinquishable message from the tty module. (the problem is in VTIME>0 VMIN=0 - the timoute must be invoked from the requesting code (strwrite()) not the line displine which may not even be called) Also note that any new TCXXX style ioctl also needs to have corresponding code in strioctl (size and direction information has to be hard coded). However I would not call these `changes to the mechanism'.
rwhite@nusdhub.UUCP (Robert C. White Jr.) (07/06/88)
in article <379@halley.UUCP>, bc@halley.UUCP (Bill Crews) says: > > Really? SVID, Issue 2, Volume describes TLI, which is so close to sockets that > many wonder why a new facility was introduced. The implementation differs, but > that wasn't the question. Pardon my showing my dis-information ;-) but I would like to know what the (omitted) "sockets" are. I have been up to my elbows in SVR3 for a while and this bit above now has me totally confused. The level of interaction of a TLI compliant device seems different than the level at which "sockets" seem to be refrenced; my confusion seems to stem from several vague refrences, to whit: When people talk about "sockets" they always seem talk about an "internal" issue, relating to the selection of one from a group of related endpoints (as relates to a driver module c.f. /dev/starlan becomes /dev/stx00-32). This is present in STREAMS through the "clone open" where the open of a master device results in the actual opening of a device segment or channel. Is this a "socket" or something like it? If this is true, then the above refrence to TLI makes no sense to me. TLI is just a method of genericly establishing "connections," in the form of virtual circuts, between two "names" which may or may not be on a generic and or homogenous network. That is to say, MS-DOS drivers may be made "TLI conformant" without ever getting UNIX related. From what I have gleaned, "sockets" are congruent to STREAMS "clone opens" but if this is the case, what would you need to change in streams? Rob.
dougm@ico.ISC.COM (Doug McCallum) (07/06/88)
In article <1093@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: ... >When people talk about "sockets" they always seem talk about an "internal" >issue, relating to the selection of one from a group of related endpoints >(as relates to a driver module c.f. /dev/starlan becomes /dev/stx00-32). >This is present in STREAMS through the "clone open" where the open of >a master device results in the actual opening of a device segment or >channel. Is this a "socket" or something like it? Using TLI/Streams to give comparisions, sockets provide basically the same functionality as TLI+clone open. The functionality is very similar. Sockets happen to do all the work in the kernel and not partially in the application library like TLI. Also, sockets identify protocols by number and not by a device. Sockets don't necessarily go through the file system. TCP/IP, for example, never appears in the file system and the call to "socket" does the equivalent of the "t_open" call. Where sockets have an advantage over current V.3 TLI is that on a large system where you might want more than 256 virtual circuits supported, a true socket implementation would work but TLI would have to have multiple major devices or move to a larger minor device number size. The socket abstraction also supports binding to addresses and establishing connections, setting options, etc. In essence, they do the same types of things that TLI does. The differences are more philosophy than anything else. > >From what I have gleaned, "sockets" are congruent to STREAMS "clone >opens" but if this is the case, what would you need to change in >streams? Sockets provide for multiple protocol support and everything else that TLI does. It is possible to implement sockets (or something real close) in the Streams environment, but the TLI (actually the Transport Provider Interface) does not have the flexibility to implement all of the semantics unless the underlying implementation has hooks to work around the TPI limitations. Some of the areas where TLI/TPI (assuming standard AT&T implementation) won't do what sockets do are: provide a way for a child process which inherits a TLI descriptor to find out the address it is connected to. provide a way for a process to find out which protocol options are set. (I don't care what the defaults are, I want to know what they are now.) set options (like TCP buffer size) after a connection is established. send datagrams (unit data) larger than 4K. These are mostly nits, but sockets have these capabilities and I've hit them all while trying to port applications from a socket environment to TLI. The one case that TLI doesn't even have even close to the mechanism that sockets have is in the case of TCP urgent data. This almost maps to expedited data, but expedited data is in-band. There is no way to signal the process that this data has appeared in the data stream until it reaches the front of the Stream head. sockets provide a signal for async notification and an ioctl to query. It makes it difficult to use urgent data for things like data stream flushing if you can't detect the urgent data until you read it. TLI also has some advantages over sockets. In a full implementation, a server can accept or reject connections based on any critieria it wants. The connection requests are handed to the server before the connections are established and are normally only established if the server accepts. TLI has more flexibility in handling connections and options.
ka@june.cs.washington.edu (Kenneth Almquist) (07/10/88)
> These are mostly nits, but sockets have these capabilities and I've > hit them all while trying to port applications from a socket > environment to TLI. The one case that TLI doesn't even have even > close to the mechanism that sockets have is in the case of TCP urgent > data. This almost maps to expedited data, but expedited data is > in-band. There is no way to signal the process that this data has > appeared in the data stream until it reaches the front of the Stream > head. Sockets provide a signal for async notification and an ioctl to > query. It makes it difficult to use urgent data for things like data > stream flushing if you can't detect the urgent data until you read it. TLI includes support for "out of band" data which has priority over normal data. My streams manual is back in New Jersey, so I can't check whether it provides notification via signals, but some sort of support for this feature is there. It is not usable with TCP because the TCP protocol does not include a facility to permit out of band data. The urgent data pointer in TCP is intended to allow all the data written up to a given point to be made available to the receiver as soon as possible. The Berkeley sockets facility, unlike TLI, does not allow the user to determine whether the underlying protocol supports out of band data. Probably for that reason, the Berkeley TCP implementation includes limited support for out of band data. The idea they used is that since their implementation of TCP makes all data available to the receiver as soon as it arrives, the intended function of the urgent data pointer is not needed with their implementation. They therefore decided that, when the user specifies that a block of data is to be made available to the user as soon as possible, the last byte of the block should be treated as out of band data. This is a poor way to implement out of band data. In particular flow control on normal data will also hold back the "out of band" data, which destroys one of the main reasons for having out of band data in the first place. It is not hard to implement out of band data on top of TCP. Multiplex the out of band and regular data onto a single TCP connection using some scheme to allow you to distinguish between the two. Make your program read data as the data arrives, using SIGPOLL. The out of band data can be processed directly inside your signal handler for SIGPOLL, while in band data can be put on a queue. Reading the data when it arrives will keep the flow control in TCP from going into effect. Implement your own flow control for in band data only by acknowledging in band data as it is processed. An alternative is to use two TCP connections, one for in band data and the other for out of band data. In any case, there is in my view little justification for using nonstandard extensions to TCP to get out of band data since this feature can be build (with a few deficiencies relating to retransmission) on top of standard TCP. Kenneth Almquist
guy@gorodish.Sun.COM (Guy Harris) (07/12/88)
> This requires a small change in strwrite() and a distinquishable message from > the tty module. However I would not call these `changes to the mechanism'. *I* would call them that; adding a new message for these purposes *does* change the mechanism. In any case, you can't do it without changing "strread()" (which is what you meant, not "strwrite()"), which is the real point here.
dougm@ico.ISC.COM (Doug McCallum) (07/17/88)
In article <5252@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: ... >The urgent data pointer in TCP is intended to allow all the data written >up to a given point to be made available to the receiver as soon as >possible. The Berkeley sockets facility, unlike TLI, does not allow >the user to determine whether the underlying protocol supports out of >band data. Probably for that reason, the Berkeley TCP implementation >includes limited support for out of band data. The idea they used is This is definitely a deficiency of sockets, but I would assume that it is the ambiguity of what URGent data means in TCP that resulted in little support. TCP URGENT does not correspond with out of band. It is an entirely different beast. >that since their implementation of TCP makes all data available to the >receiver as soon as it arrives, the intended function of the urgent data >pointer is not needed with their implementation. They therefore decided Urgent is still needed. The intent of urgent is not to push the data to the user (the PUSH bit does that) but to indicate that data be treated differently. In order to implement the TELNET protocol (and even rlogin)) properly requires urgent data support in the TCP sense and not in the TLI expedited data sense. >that, when the user specifies that a block of data is to be made available >to the user as soon as possible, the last byte of the block should be >treated as out of band data. This is a poor way to implement out of band >data. In particular flow control on normal data will also hold back the >"out of band" data, which destroys one of the main reasons for having >out of band data in the first place. But that is how TCP specifies urgent data - it indicates the end of the urgent data and not the beginning or length. > >It is not hard to implement out of band data on top of TCP. Multiplex >the out of band and regular data onto a single TCP connection using some ... >the other for out of band data. In any case, there is in my view little >justification for using nonstandard extensions to TCP to get out of band >data since this feature can be build (with a few deficiencies relating >to retransmission) on top of standard TCP. While you can simulate TLI expedited data, it still doesn't give TLI a way to use TCP urgent data in the way TCP urgent data is intended to be used. You really want the urgent data to be inline with normal data but have an indication that is truly out of band of where the urgent data ends in the data stream. Sockets gives you this by letting a program query whether there is urgent data (out of band in socket terms) in the data stream or get a signal whenever there is. The program can also read the out of band data explicitly or let it be read as part of the data stream. TLI only generates a signal when data arrives at an empty Stream head which means you might not get a signal when expedited data arrives. The result is that it is difficult to implement a true TELNET implementation with just the facilities provided in TLI. Pulling it completely out of band and sending it upstream before other data doesn't work since you lose the position information which is just as important as the fact that there is urgent data in the stream. Leaving it in place but not signalling the process in some way that urgent data exists means you don't find it until you read it which means that you have lost the function that it is used for in TELNET. Emulating something else doesn't buy you anything since no non-TLI implementations will be using your emulation.