Subject: Re: corba or sockets?
From: Erik Naggum <>
Date: 31 Oct 2000 18:36:55 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Wade Humeniuk <>
| 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.

  Does anyone remember where I parked Air Force One?
                                   -- George W. Bush