hagens@CS.WISC.EDU (Robert Hagens) (11/18/87)
Bill Crews writes about TLI: > One reason it might be better is that it makes no assumptions about the > underlying protocols -- or, I should say, minimal assumptions. For instance, > connection-oriented service, a "byte-stream" mode is supported. Some > underlying protocols may allow preservation of message boundaries and some may > not. The application programmer can maintain portability by refraining from > making that assumption. Nothing in TLI forces that assumption. Does TLI allow one to take advantage of the message boundaries? ISO session depends on the message boundaries provided by ISO transport. If it does not, you may find yourself in trouble when you try to support an OSI stack. Rob Hagens UW Madison Computer Science ARGO project
narayan@lll-ati.arpa (Narayan Moharram) (11/21/87)
In article <8711181601.AA00849@janeb.wisc.edu> hagens@CS.WISC.EDU (Robert Hagens) writes: > >Does TLI allow one to take advantage of the message boundaries? ISO session >depends on the message boundaries provided by ISO transport. If it does not, >you may find yourself in trouble when you try to support an OSI stack. > >Rob Hagens >UW Madison Computer Science >ARGO project Yes it does indeed. Each read / t_recv gets you one packet only, if the underlying protocol maintains packet boundaries (For that matter so does the socket interface). However it is the interpretation of urget data in TLI that bugs me.
bc@halley.UUCP (Bill Crews) (11/26/87)
In article <8711181601.AA00849@janeb.wisc.edu> hagens@CS.WISC.EDU (Robert Hagens) writes: >Bill Crews writes about TLI: > >> One reason it might be better is that it makes no assumptions about the >> underlying protocols -- or, I should say, minimal assumptions. For instance, >> connection-oriented service, a "byte-stream" mode is supported. Some >> underlying protocols may allow preservation of message boundaries and some may >> not. The application programmer can maintain portability by refraining from >> making that assumption. Nothing in TLI forces that assumption. > >Does TLI allow one to take advantage of the message boundaries? ISO session >depends on the message boundaries provided by ISO transport. If it does not, >you may find yourself in trouble when you try to support an OSI stack. Does the *service* or the *protocol* need to "take advantage of message boundaries"? TLI does allow one to specify a T_MORE flag as part of the service interface. This allows a large message to be sent or received in morsels small enough to digest, but still be considered one message. Does this satisfy your concern. That's about all the *interface* says about boundaries, and, it seems to me, all it should say. I haven't implemented ISO transport accessed via TLI (or anything else), but a number of others have, with no problems I've heard about. -bc -- Bill Crews Tandem Computers Austin, Texas ..!rutgers!im4u!esc-bb!halley!bc (512) 244-8350
martillo@husc11.HARVARD.EDU (Yakim Martillo) (11/30/87)
Ur-Unix had files which provided single data streams from single data sources. Pipes provided a simultaneous rendezvous between two processes over a full duplex stream. (Pipes in fact are a special kind of file.) These Ur-Unix concepts were inadequate for data communications and computer networking where a process might only be interested in one sub-stream of a multiplexed data stream coming from multiplexed sources. Further in a network environment simultaneous rendezvous between two process might not be possible. To replace simultaneous rendezvous, the Berkeley network designers introduced the client-server model which in fact replaces the process pair with one server and many clients which is particularly useful in decreasing load on network server machines. To deal with the problem of multiplexed data streams from multiplexed sources, and in order to realize the client-server model the Berkeley designer implemented the socket interface. Socket and bind provide a handle into multiplexed data streams. Accept, listen and connect help realize the client server model. Since files and pipes are just simple special cases of (singly) multiplexed data streams and rendezvous, the socket formalism provides a unified and effective formalism to files, streams, data communications and computer networking. Using sockets effectively reduces the "dimension" of interprocess communication problems and therefore should be the formalism of choice for implementing network software. [It is particularly nice that blocking and asynchronous I/O on terminals (a special case of a file), on files, on pipes and on sockets all behave identically.] I was unimpressed by the original streams designed by Ritchie who obviously understands the Unix model of computation. The Sys 5 designers who do not understand the Unix model of computation have apparently botched the implementation from what I amP+O_Z
martillo@husc11.HARVARD.EDU (Yakim Martillo) (11/30/87)
Steve Dyer correctly pointed out to me that Full-duplex is not the correct term for describing a pipe. Pipe returns two file descriptors. If the process forks, the child inherits the same read and write pointers as the parent. Using dup or dup2 either process can get its own read and write pointers into the pipe. If the parent and child continue to share the same read and write pointer, the parent could write into the pipe and then the child could drain it. Then the child could write into the pipe and the parent could drain it. If parent and child read and write simultaneously, the result is probably a mess. Maybe bidirectional is a better term for this. Also I meant asynchronous and non-blocking I/O work identically on terminals, files, pipes and sockets in the socket formalism. If there are anymore errors in this, they are mine and not Steve's.
henry@utzoo.UUCP (Henry Spencer) (12/03/87)
> To deal with the problem of multiplexed data streams from multiplexed > sources, and in order to realize the client-server model the Berkeley > designer implemented the socket interface. Unnecessarily, since all those things can be done with the old interface given some thought and care. Alas, it's often tempting, not to mention exciting, to charge in and implement something new rather than thinking carefully about how it could fit in with the old way of doing things. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
martillo@husc11.HARVARD.EDU (Yakim Martillo) (12/05/87)
In article <9033@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
:: To deal with the problem of multiplexed data streams from multiplexed
:: sources, and in order to realize the client-server model the Berkeley
:: designer implemented the socket interface.
:Unnecessarily, since all those things can be done with the old interface
:given some thought and care. Alas, it's often tempting, not to mention
:exciting, to charge in and implement something new rather than thinking
:carefully about how it could fit in with the old way of doing things.
:Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology
:condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
I have done this at the Labs using Sys5 it usually involved writing
a bunch of new ioctls and creating a bunch of pseudodevices.
I don't see how this is particularly cleaner than sockets. Maybe
somebody at the labs could ask Ritchie but I don't think the Unix
designers initially had any thought to deal with multiplexed streams
of data from multiplexed sources. If they had, Ur-Unix would have had
select() because select() is really helpful for writing network code.
In fact select() did not appear in AT&T Unix until 5V3. I found
rendezvous between processes on two machines to be really painful
using the Sys 5 interface.
By creating streams Ritchie basically was expressing the view that
the old interface was inadequate for multiplexed data streams and
protocol stacks.
Now I think streams in Ritchies implementation are okay, I just don't
feel they lend themselves to offloading lower protocol levels to a
network front-end processor. Sockets do somewhat better with such
hardware configurations.henry@utzoo.UUCP (Henry Spencer) (12/09/87)
> By creating streams Ritchie basically was expressing the view that > the old interface was inadequate for multiplexed data streams and > protocol stacks. Yes, and you'll notice that the new machinery was a modest extension of the old -- basically the ability to stack line disciplines rather than just choosing one -- rather than a complete re-invention of the wheel. > Now I think streams in Ritchies implementation are okay, I just don't > feel they lend themselves to offloading lower protocol levels to a > network front-end processor... Gee, we're planning to do precisely that using Ritchie streams (not the SysV version, which one of my less diplomatic friends calls "sewers") and we see no significant problems. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
martillo@husc11.HARVARD.EDU (Yakim Martillo) (12/13/87)
In article <9080@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
:: By creating streams Ritchie basically was expressing the view that
:: the old interface was inadequate for multiplexed data streams and
:: protocol stacks.
:Yes, and you'll notice that the new machinery was a modest extension of
:the old -- basically the ability to stack line disciplines rather than
:just choosing one -- rather than a complete re-invention of the wheel.
:: Now I think streams in Ritchies implementation are okay, I just don't
:: feel they lend themselves to offloading lower protocol levels to a
:: network front-end processor...
:Gee, we're planning to do precisely that using Ritchie streams (not the
:SysV version, which one of my less diplomatic friends calls "sewers")
:and we see no significant problems.
Just out of curiosity, how many protocol layers are being off-loaded
onto your front-end processor or intelligent controller. If more than
one layer is being off-loaded, the descriptions I have read of streams
seem to imply that streams would have to be implemented on the controller.
Now that might not necessarily be bad, but I would have to think about it.