Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!acc.com!fbaker
From: fbaker@acc.com (Fred Baker)
Newsgroups: comp.protocols.iso.dev-environ
Subject: Re:  distributed programming language/ISODE
Message-ID: <9106121538.AA18799@emerald.acc.com>
Date: 12 Jun 91 15:38:52 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 64

>> "to build the one-to-many RPC/Rendezvous-like communication aspect of
>> my DPL on top of the transport layer (or higher layers) of the ISO/OSI
>> reference model using multicast communication semantics (n *
>> point-to-point)".  I intend to use ISODE to implement the communication
>> aspects of my DPL.

I am not altogether sure what you mean, in your note, by ISO/OSI
communication.  I think you are refering to the use of one of the ISO
stacks (X.25/CONS/TP0 or CLNS/TP4 or CLNS/CLTS); if so, the fundamental
premise of ISODE is that the underlying service isn't particularly
relevant if it can be made to provide a communication service having
the intended characteristics - isode in fact runs over IP/TCP or IP/UDP.

The issue you are going to get into using ISODE, I suspect, is that it
doesn't define a multicast service - it defines ways to have duplex
communications with many peers, not n-plex communications with a set of
peers.  You are going to have to engineer the n-plex service.

>> As far as I know there is no DPL which communication aspects are based
>> on ISO/OSI-communication. Therefore I want to start with a fundamental
>> question.

While it's not quite what you asked, you might want to consider OCCAM.
It describes a relationship between processes which are not presumed to
be in the same processor, but which ARE presumed to be connected by
reliable simplex data streams.  Implementation of what they call the
Communicating Process Architecture on top of a classic transport
service should be fairly straightforward.

>> Are there fundamental reasons against basing the (low level)
>> communication aspects of a DPL on the transport layer (or higher ones)
>> using ISODE ?  (Why and are there articles which discuss/demonstrate
>> usefulness or not?)

No, as experience with Courier (XNS) and RPC (Sun) have demonstrated in
practice.  SNMP was originally implemented using pieces of ISODE.

>> Should the inherent performance-lack of the ISO/OSI-communication be an
>> arguement not to use it for DPLs? (Are there other arguements that
>> dominate performance-issues?)

X.25 is pretty miserable for performance, but TP4 on CLNS is not
inherently much different than TCP on IP; the big differences are in
the checksum calculations, the NSAP/Address lookup, and the fact that
the installed software base lacks maturity.  If X.25 is limiting your
options, use something that doesn't.

>> How can I use ISODE to build protocols that use (reliable) multicast
>> communication? (Do you have some simple examples?)

>> Do you know about research in building (object-based, object-oriented,
>> ...) DPLs which use ISO/OSI-communication (resp. ISODE)?

I would suggest that you contact Steve Deering at Xerox PARC.  He has
done a fair amount of research on general multicast technologies, and
written some RFCs dated 1985->last year.

You should also contact Craig Partridge.  When SNMP and CMOT were first
being seriously considered by the IETF, he was championing a third
approach called HEMS, in which he viewed the network as a database
accessable by a query language/protocol.  He probably has some insights
which would apply to your application.

Fred