Subject: Re: corba or sockets? From: Erik Naggum <erik@naggum.net> Date: 31 Oct 2000 18:36:55 +0000 Newsgroups: comp.lang.lisp Message-ID: <3182006215264531@naggum.net> * Wade Humeniuk <humeniuw@cadvision.com> | They are fine protocols, but only as transport and network layer | protocols. What does this mean? It makes absolutely no sense at it stands. | The whole conceptual framework of protocols I think is best | described by the OSI reference model. Not at all. Only some frameworks are describable in ISORMOSI, specifically those that actually used it while being described. Please note that the full name is the _ISO_ Reference Model for Open Systems Interconnection. It's their model. It is _not_ a model that explains or can describe all Open Systems Interconnection. See The Elements of Networking Style: And Other Essays & Animadversions on the Art of Intercomputer Networking by M. A. Padlipsky for a full coverage of this. ISBN 0-595-08879-1. | TCP and IPv4 only live within the context of the data link and | physical layer protocols that carry them. This is false. | All the issues of reliability, delivery and such need to be looked | at as protocol stacks. If you use the ISORMOSI on the Internet, you will end up with very, very weird attitudes towards a very fine technology, sort of like the people who believe that now that we have 8-bit byte-adressable machines, the concept "byte" is conflatable with "octet", and then their heads explode when other concepts of "byte" present themselves to them. | For those that want to learn about protocols break open the OSI spec | on the reference model. Anybody remember the ISO spec number? I | don't have it handy anymore. I would recommend against ISORMOSI until you understand whence it came, that is: the history of protocol design preceding it, both within the CCITT/ITU and the ISO camps and without either. There are very different cultures at work, here. That's a contributory reason that TCP/IP won. "If ISORMOSI really was so great, how come nobody talks their protocols?" actually applies. | The major problem with the Telecom protocols I have found has been | their defintions of their protocol data units which place a premimum | on reducing the number of bits in network traffic. You _really_ want this, but perhaps you need to work with these guys to realize that 1% more protocol overhead means 1% more money to buy the same bandwidth, or slower deployment due to higher costs, etc. | This makes the PDUs hard to parse. That does not follow _at_all_. | A great example of this, if you can get the spec is IS-634, the | control protocol between Cellular Base Stations and Management | systems. Whoever dreamed that up has never programmed a computer | before. I'm making an unsubstantiated guess here, much like you do, and would counter that he probably does protocol implementation in dedicated chips. So would you if you dealt that these things. | Also the telecom protocols (at least the cellular ones) are tending | to define the protocol state machines in SDL which allows protocol | designers to leave gaps of what happens when error conditions occur. I have worked a little with SDL, but that is years ago, but most of what I have worked with in the Telecom world has been described with SDL (Z.100) or 'variations" like Estelle. | ASN.1, what can I say, another language to learn. Liking Lisp, I | think a Lisp external syntax should be used for a platform | independent encoding of PDUs. It takes more bytes but it transports | well (and I can see it clearly on a data scope). Notice that ASN.1's encoding rules are actually parsable with the same ease as (most) Lisp objects (that is, excluding symbols, which are a pain insofar as they overlap syntactically with numbers). I see a very clean mapping between ASN.1 and Lisp, qua languages to describe and encode data. | I am still divided on the issue of creating protocols between | cooperative machines/processes or going for a distributed OS view | where everything is one large memory space. I thought that is what | CORBA is offering, one large memory space. There is room for both | of them, a distributed OS at some lower level must implement | protocols. Does a programmer have to see that? If you do the global memory thing, at least figure out the need for cache coherence and propagation protocols. Nobody I talked to about CORBA have had the faintest clue what that would entail for CORBA, so I gave up talking to these guys. (This was not in a Lisp context, BTW.) About half of what I have done over the years has had to do with ensuring that lots of computers very far apart agree to what the world looks like at exactly the same time. "One large memory space" sort of covers it, since the idea is that through intelligent protocols and very careful programming, lots of computers actually get the same values without having to ask anyone _else_ for them. There are several interesting products that offer some of this functionality for databases, messages servers, etc, these days. I'm not sure a programmer needs to see everything, but being able to ensure that you have the information you need in time requires work, and I fail to see how anyone but programmers should do that. Like TCP and IP do not live quietly down in the basement, but actually extend their services and _presence_ all the way up to the "application layer" (and you _really_ want this, by the way), there is no way you can avoid knowing about "the underworld" relative to your actual interests. If you think you can avoid it, you are only saying that you are willing to accept some set of default behaviors, but if you don't know what they are, you are also likely to be wrong. The belief in cleanly separated layers is almost a religion. It has no basis in reality or experience, but there is nothing that can make someone who believes in it stop believing in it. There's always an answer for why it's a good idea despite all the hairy stuff they have to deal with. Just like the whole ISORMOSI thing. And almost like the belief in structured programming and object orientation where the only time anyone can be trusted to use them well is when they know when _not_ to use them. Make that a more general assertion: If you think you have an answer for everything, the answer is probably not right for anything. If you have an answer for some things, the answer is probably right for those things. #:Erik -- Does anyone remember where I parked Air Force One? -- George W. Bush