3 ms·

Wow. That is awesome, I skimmed through it and it looks like something I will enjoy. I've still got my Tanenbaum Computer Networks book from 1996 and the firs

Wow. That is awesome, I skimmed through it and it looks like something I will enjoy. I've still got my Tanenbaum Computer Networks book from 1996 and the first chapter starts with OSI, then TCP/IP, and explains the differences and why OSI failed.

kragen 2y ago
I'm interested to hear what you think! I haven't finished reading it yet. It's a bit repetititive.
- OhMeadhbh 2y ago
  It doesn't seem like a "take down" as much as a re-iteration of all the things IBM, DEC, GE and various Telcos did wrong when implementing OSI. I could reduce it to one sentence: "Everyone was so intent on monetizing their own networking implementation they never thought enough about interoperability."
  - kragen 2y ago
    Not only isn't that an accurate summary of Graham's book, it isn't even a topic discussed in the first half of the book, which is all I've read so far. I suspect it isn't a topic discussed in the book at all; can you back up your assertion with some quotes?
    - OhMeadhbh 2y ago
      Yes, but the book also has enough inaccuracies as to make it... I don't know what. For example, in the first chapter the author says "no one knows what a session is," which is patently false. I myself implemented control logic in telco equipment to respond to X.225 compliant messages to change the state of an abstract state machine used on either side of the connection. And while I'm sure it's possible to use CONS or CLNP to communicate with a CEEFAX terminal, that is far from the only use to which the various OSI compliant protocols were put. Just because you don't understand something, that doesn't mean it's bad.
      - kragen 2y ago
        I think he means to be saying that, in the context of TCP/IP, nobody knows what a “session” in the OSI sense would correspond to—not that nobody has ever implemented X.225. Presumably Graham knows that people have written X.225 implementations and isn't trying to convince his readers otherwise? I don't know enough to judge his assertion that the session layer exists to solve problems created by half-duplex terminals. (He doesn't seem to specifically call out Ceefax.)
        OhMeadhbh 2y ago
        From page 11: "OSI was designed primarily around the dumb terminal connected to a mainframe." Also from page 11: "'session' meant something related to attaching videotex terminals to mainframes." And yes, all Ceefax terminals were Videotex terminals, but not all Videotex terminals were Ceefax terminals. I might recommend that instead of guessing what the session layer is, you (or more appropriately, Mr. Graham) go and look at what the specs say it is and what it's used for. The X.225 spec is available for download at https://www.itu.int/rec/T-REC-X.225-199511-I/en https://www.itu.int/rec/T-REC-X.225-199511-I/en. X.215 is available at https://www.itu.int/rec/T-REC-X.215-199511-I/en https://www.itu.int/rec/T-REC-X.215-199511-I/en. The OSI session layer is not related to HTTP session cookies as the original author proposes.
        kragen 2y ago
        Hey, thanks! I had looked for it when writing my previous comment, but I skipped past the ITU links on the assumption that I'd have to sign over my first-born children in order to get a copy. But it turns out that they aren't currently restricting its availability: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.225-199511-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22... Clearly "videotex" is wrong. Skimming X.225, though, an awful lot of it does seem to be concerned with ⓐ half-duplex terminals and ⓑ T.62 teletex (not videotex, closer to telex) terminals. So "attaching video terminals to mainframes" does seem like a fair summary. Possibly Graham doesn't know what the word "videotex" means, or thought (as I did, neither of us having lived in Germany) that "teletex" was a kind of videotex. I agree that it doesn't have the kind of functionality that HTTP cookies provide. That's backwards, I think? HTTP cookies provide session context that persists over multiple TCP-level connections; the reuse of a single transport connection between different X.225 sessions is more like reusing a single TCP-level connection for multiple HTTP requests, or multiple users logging in and out, one after the other, on the same hardwired terminal without resetting it? I wish it gave examples of usage so I knew what the resynchronization functionality was for. Maybe you know? Expedited data is a thing that TCP also has, and I've never really understood what it was for there either. Maybe it's for sending a ^C over a remote terminal login session when the keyboard buffer is full because the application you're talking to is hung? The "activity interrupt" stuff seems like it would be a better fit for that, but maybe the expedited data facility was an older design that was retained for backward-compatibility?

kragen 2y ago

I'm interested to hear what you think! I haven't finished reading it yet. It's a bit repetititive.

OhMeadhbh 2y ago
It doesn't seem like a "take down" as much as a re-iteration of all the things IBM, DEC, GE and various Telcos did wrong when implementing OSI. I could reduce it to one sentence: "Everyone was so intent on monetizing their own networking implementation they never thought enough about interoperability."
- kragen 2y ago
  Not only isn't that an accurate summary of Graham's book, it isn't even a topic discussed in the first half of the book, which is all I've read so far. I suspect it isn't a topic discussed in the book at all; can you back up your assertion with some quotes?
  - OhMeadhbh 2y ago
    Yes, but the book also has enough inaccuracies as to make it... I don't know what. For example, in the first chapter the author says "no one knows what a session is," which is patently false. I myself implemented control logic in telco equipment to respond to X.225 compliant messages to change the state of an abstract state machine used on either side of the connection. And while I'm sure it's possible to use CONS or CLNP to communicate with a CEEFAX terminal, that is far from the only use to which the various OSI compliant protocols were put. Just because you don't understand something, that doesn't mean it's bad.
    - kragen 2y ago
      I think he means to be saying that, in the context of TCP/IP, nobody knows what a “session” in the OSI sense would correspond to—not that nobody has ever implemented X.225. Presumably Graham knows that people have written X.225 implementations and isn't trying to convince his readers otherwise? I don't know enough to judge his assertion that the session layer exists to solve problems created by half-duplex terminals. (He doesn't seem to specifically call out Ceefax.)
      - OhMeadhbh 2y ago
        From page 11: "OSI was designed primarily around the dumb terminal connected to a mainframe." Also from page 11: "'session' meant something related to attaching videotex terminals to mainframes." And yes, all Ceefax terminals were Videotex terminals, but not all Videotex terminals were Ceefax terminals. I might recommend that instead of guessing what the session layer is, you (or more appropriately, Mr. Graham) go and look at what the specs say it is and what it's used for. The X.225 spec is available for download at https://www.itu.int/rec/T-REC-X.225-199511-I/en https://www.itu.int/rec/T-REC-X.225-199511-I/en. X.215 is available at https://www.itu.int/rec/T-REC-X.215-199511-I/en https://www.itu.int/rec/T-REC-X.215-199511-I/en. The OSI session layer is not related to HTTP session cookies as the original author proposes.
        kragen 2y ago
        Hey, thanks! I had looked for it when writing my previous comment, but I skipped past the ITU links on the assumption that I'd have to sign over my first-born children in order to get a copy. But it turns out that they aren't currently restricting its availability: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.225-199511-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22... Clearly "videotex" is wrong. Skimming X.225, though, an awful lot of it does seem to be concerned with ⓐ half-duplex terminals and ⓑ T.62 teletex (not videotex, closer to telex) terminals. So "attaching video terminals to mainframes" does seem like a fair summary. Possibly Graham doesn't know what the word "videotex" means, or thought (as I did, neither of us having lived in Germany) that "teletex" was a kind of videotex. I agree that it doesn't have the kind of functionality that HTTP cookies provide. That's backwards, I think? HTTP cookies provide session context that persists over multiple TCP-level connections; the reuse of a single transport connection between different X.225 sessions is more like reusing a single TCP-level connection for multiple HTTP requests, or multiple users logging in and out, one after the other, on the same hardwired terminal without resetting it? I wish it gave examples of usage so I knew what the resynchronization functionality was for. Maybe you know? Expedited data is a thing that TCP also has, and I've never really understood what it was for there either. Maybe it's for sending a ^C over a remote terminal login session when the keyboard buffer is full because the application you're talking to is hung? The "activity interrupt" stuff seems like it would be a better fit for that, but maybe the expedited data facility was an older design that was retained for backward-compatibility?