bochannk@hwsw.gedas.de (Alexander Bochannek) (05/11/91)
Hi! Let me quote Marshall T. Rose "In OSI, a reference model is used to describe computer communications. The Model is inherently abstract. It does not specify: - programming language bindings, - operating system bindings, ..." So, what does this mean? It means, everybody is free to implement the protocols as he likes. But, hey, we have this neat layer structure and we have this primitives. I don't know ISODE in detail, so I don't know how the inter-protocol communi- cation is made. What does the community think about this approach: - each protocol is one seperate process (I know what Comer thinks about this) - inter-protocol communication is through an IPC facility (I vote for a mixture of messages and shared memory, but this is yet to be discussed) - through this communication path the protocol processes send primitives - the configuration of which process is allowed to talk to which other is (in the best case dynamically) handled by one central networking daemon - the files associated with each protocol could be hold in a seperate directory structure like /net/layer-number (This is because it is frustrating to search for configuration files throughout the whole system) - the hardware access part (layer one and MAC for Ethernet) need not necessarily be implemented as a device driver but as the same kind of process as the other layers (for exchangeability's sake) These are just some ideas which came to my mind reading OSI books and being frustrated with my daily work administering our local TCP/IP net and the connection to the Internet. OK, if anybody out there likes these ideas, wants to discuss them or just likes to flame me because I'm sooo stupid and ISODE already has similar or better features, email me. Alex
csg@pyramid.pyramid.com (Carl S. Gutekunst) (05/13/91)
>It means, everybody is free to implement the protocols as he likes. No, the language and operating system bindings can be done however you like. (And in fact, they are done lots of different ways.) The protocols, however, are defined by the standards. Various industry groups (including X/Open and UI) are busily working to define bindings. This is a very good thing, IMHO. But it is a very different thing from defining protocols. I just reviewed two different application programmer interfaces to X.25. They were quite a bit different, and have consider effect on the architecture of the programs that would use them. But the X.25 packet- layer protocol is unaffected. >- each protocol is one seperate process (I know what Comer thinks about this) The preferred implemention in commercial UNIX these days is each protocol (or other logical division) in a streams module, in the kernel. Applications chose the pieces that they need, and string them together. For example, an X.400 '84 RTS would push an appropriate transport and the session layers; an X.400 '88 RTS would also need to push the presentation layer and ACSE. >These are just some ideas which came to my mind reading OSI books and being >frustrated with my daily work administering our local TCP/IP net and the >connection to the Internet. Um, if you are frustrated administering a TCP/IP network, you ain't seen nothing yet. Present day OSI stacks require vastly more administrative work, as well as far more network understanding, than any modern TCP/IP network. We are a long way from even designing (let alone implementing) the tools that will make the OSI stack easily managable. <csg>