3 ms·

For my job I had the opportunity to work with quite some OSI standards on top of TCP/IP (X.216, X.227 and X.500, X.400 as application layers). My experience is

by wogna 9y ago

For my job I had the opportunity to work with quite some OSI standards on top of TCP/IP (X.216, X.227 and X.500, X.400 as application layers). My experience is quite in line with the common critique: most of these standards add more overhead than they're worth. It was also quite hard to bend these protocols into our use case (when bandwidth comes at a premium, it doesn't take long before the customer starts complaining). I don't really see how a "dumb terminal" is a noteworthy feature of OSI? That's essentially what telnet does, and it too can just piggyback on top of TCP (probably the only protocol that makes use of all TCP flags available).

oldandtired 9y ago
What commercial software were you using? TCP/IP was not part of the protocol stack we were using. The dumb terminal was sitting at the top of the protocol stack and wasn't using an application like telnet to access remote devices or applications. The point of my example was simply that a dumb terminal or any device or an application were treated the same in relation to the protocol stack. It did not matter. The top speed of our links was the enormous 64 kb/s and we often had to use far slower services. We found that the overheads of the communication protocols was very small compared to the application processing overheads. It was a different time, I suppose and I find that I have to wait longer these days even when using ADSL than I did in those days.