7 ms·

For anyone needing context, STREAMS was SysV's competing API for I/O. https://en.wikipedia.org/wiki/STREAMS https://en.wikipedia.org/wiki/STREAMS

JohnMakin 3y ago
so I'm guessing this response nailed why it didn't catch on: >Regardless of what the wave of the future is, presently if you write to the TLI interface you won't be able to compile your code on a socket-only system whereas if you use the socket interface you'll be portable to most TLI systems (since they usually come with socket interface libraries). If you aren't concerned about optimal efficiency, writing to the socket interface now would be more portable.
- thriftwy 3y ago
  > The disadvantage is that you can't write programs like FTP or sendmail using the RPC protocol. Not programs that will interoperate with other FTP's and sendmails, at any rate. > While RPC is good for some things, it is not the answer to all the networking problems. Sometimes you just gotta write at a fairly low level to interoperate with other programs.
- dan-robertson 3y ago
  My understanding was that the thinking at the time was that the IP family protocols (ie tcp, udp, etc) would soon be replaced by OSI protocols and the sockets api was too tightly coupled with IP protocols and so your applications would need more difficult upgrades in the future if you wrote them against sockets. But your quotation disagrees with that claim. I think part of the implied benefit of the epic library is that it would seamlessly transition when the new OSI protocols were used. Obviously, we now know that the OSI protocols didn’t get used (unless you count ldap or x509 or everyone talking about layers all the time) and so the more flexible api was not required.
  - logronoide 3y ago
    That’s what our “Teleinformatics” professors taught to us early in the 90’s at the university. OSI protocols were promising but adoption was not clear.
  - saghm 3y ago
    > or everyone talking about layers all the time This is super funny, but also a bit of a surprise for someone born after the referenced thread occurred. As someone who only learned about the "layers" model of networks in college more than two decades after the discussion, it never occurred to me that the original intent of the model was to describe forthcoming protocols from OSI; we were just told "this layer means TCP or UDP, this layer means IP, etc.", and no one mentioned any historical context around the choices.
    - TedDoesntTalk 3y ago
      Tannenbaums network books from the late 80s also mapped the OSI layers onto TCP/UDP/IP
    - Tuna-Fish 3y ago
      For anyone interested in the historical context, I strongly recommend this blogpost on it: https://computer.rip/2021-03-27-the-actual-osi-model.html https://computer.rip/2021-03-27-the-actual-osi-model.html
- convolvatron 3y ago
  sockets seem conceptually worse than streams, but streams was a total PITA to code to. once you got something set up, it was fine, but you had to assemble the stack with a bunch of control messages, and there was very little introspection. I can't imagine pushing streams as an everyday networking interface for people
  - cryptonector 3y ago
    The application need not have a LEGO blocks picture of networking. The networking stack can, but doesn't have to have a LEGO blocks picture of networking. The OSI model is a guide, not a law.
- cryptonector 3y ago
  And also because STREAMS/TLI/XTI was awful.
  - jrpelkonen 3y ago
    I found this quote by Henry Spencer amusing: > It is important to distinguish "streams" (Dennis Ritchie's term for his revised non-block-device i/o system) from "STREAMS" (what AT&T put into System V). Dennis's streams cleaned up a lot of mess, and improved performance to boot. But as Dennis is rumored to have said, "`streams' means something different when shouted".
    - cryptonector 3y ago
      Yes, quite. At Sun we used to have a pejorative phrase "it came from NJ" which referred to code added by AT&T but which wasn't from Ritchie et. al.
dan-robertson 3y ago
https://en.m.wikipedia.org/wiki/X/Open_Transport_Interface https://en.m.wikipedia.org/wiki/X/Open_Transport_Interface describes the (slight successor to) the TLI api mentioned and has a shallow comparison table to tcp.
- detourdog 3y ago
  When Apple bought NeXT I was surprised when they dropped Open Transport. They had been touting The move from sockets to streams as the future and had finally migrated to Open Transport. I specifically remember hearing from Avie that Streams maybe technically better but sockets are so foundational that the new OS would use sockets. He felt streams just weren't an option.

JohnMakin 3y ago

so I'm guessing this response nailed why it didn't catch on: >Regardless of what the wave of the future is, presently if you write to the TLI interface you won't be able to compile your code on a socket-only system whereas if you use the socket interface you'll be portable to most TLI systems (since they usually come with socket interface libraries). If you aren't concerned about optimal efficiency, writing to the socket interface now would be more portable.

thriftwy 3y ago
> The disadvantage is that you can't write programs like FTP or sendmail using the RPC protocol. Not programs that will interoperate with other FTP's and sendmails, at any rate. > While RPC is good for some things, it is not the answer to all the networking problems. Sometimes you just gotta write at a fairly low level to interoperate with other programs.
dan-robertson 3y ago
My understanding was that the thinking at the time was that the IP family protocols (ie tcp, udp, etc) would soon be replaced by OSI protocols and the sockets api was too tightly coupled with IP protocols and so your applications would need more difficult upgrades in the future if you wrote them against sockets. But your quotation disagrees with that claim. I think part of the implied benefit of the epic library is that it would seamlessly transition when the new OSI protocols were used. Obviously, we now know that the OSI protocols didn’t get used (unless you count ldap or x509 or everyone talking about layers all the time) and so the more flexible api was not required.
- logronoide 3y ago
  That’s what our “Teleinformatics” professors taught to us early in the 90’s at the university. OSI protocols were promising but adoption was not clear.
- saghm 3y ago
  > or everyone talking about layers all the time This is super funny, but also a bit of a surprise for someone born after the referenced thread occurred. As someone who only learned about the "layers" model of networks in college more than two decades after the discussion, it never occurred to me that the original intent of the model was to describe forthcoming protocols from OSI; we were just told "this layer means TCP or UDP, this layer means IP, etc.", and no one mentioned any historical context around the choices.
  - TedDoesntTalk 3y ago
    Tannenbaums network books from the late 80s also mapped the OSI layers onto TCP/UDP/IP
  - Tuna-Fish 3y ago
    For anyone interested in the historical context, I strongly recommend this blogpost on it: https://computer.rip/2021-03-27-the-actual-osi-model.html https://computer.rip/2021-03-27-the-actual-osi-model.html
convolvatron 3y ago
sockets seem conceptually worse than streams, but streams was a total PITA to code to. once you got something set up, it was fine, but you had to assemble the stack with a bunch of control messages, and there was very little introspection. I can't imagine pushing streams as an everyday networking interface for people
- cryptonector 3y ago
  The application need not have a LEGO blocks picture of networking. The networking stack can, but doesn't have to have a LEGO blocks picture of networking. The OSI model is a guide, not a law.
cryptonector 3y ago
And also because STREAMS/TLI/XTI was awful.
- jrpelkonen 3y ago
  I found this quote by Henry Spencer amusing: > It is important to distinguish "streams" (Dennis Ritchie's term for his revised non-block-device i/o system) from "STREAMS" (what AT&T put into System V). Dennis's streams cleaned up a lot of mess, and improved performance to boot. But as Dennis is rumored to have said, "`streams' means something different when shouted".
  - cryptonector 3y ago
    Yes, quite. At Sun we used to have a pejorative phrase "it came from NJ" which referred to code added by AT&T but which wasn't from Ritchie et. al.

dan-robertson 3y ago

https://en.m.wikipedia.org/wiki/X/Open_Transport_Interface https://en.m.wikipedia.org/wiki/X/Open_Transport_Interface describes the (slight successor to) the TLI api mentioned and has a shallow comparison table to tcp.

detourdog 3y ago
When Apple bought NeXT I was surprised when they dropped Open Transport. They had been touting The move from sockets to streams as the future and had finally migrated to Open Transport. I specifically remember hearing from Avie that Streams maybe technically better but sockets are so foundational that the new OS would use sockets. He felt streams just weren't an option.