3 ms·

I have read the various comments against the OSI model and the one interesting observation is that none of you seem to have ever worked with a compliant impleme

I have read the various comments against the OSI model and the one interesting observation is that none of you seem to have ever worked with a compliant implementation of the OSI model. Honeywell had a commercial product called DSA (Distributed Systems Architecture). We did write distributed applications that used the OSI protocol stack communications and it worked well. Within the applications, we didn't have to worry much about what was happening at the lower levels as those levels simply provided specific services we used. It was used for many years with very good results. One of the features of the software at the time was that you get two dumb terminals to communicate with each other across the network by simply using the relevant connection protocols. This allowed simple communication streams to occur without having any applications involved, it was handled by the protocols themselves. It also meant that it was very easy to replace those dub terminals with an application without having to change any of the configurations in the network. TCP/IP rose to the fore due to various reasons that were not related to their technological superiority. To see this you have to look more closely to the history of those times.

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.

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.