Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gvlf3.gvl.unisys.com!tredysvr!dvnspc1!mdobbins From: mdobbins@dvnspc1.Dev.Unisys.COM (Michael Dobbins) Newsgroups: comp.protocols.iso Subject: Re: Transparent Distribution - Why no light-weight transport in OSI stack? Message-ID: <1101@dvnspc1.Dev.Unisys.COM> Date: 13 Feb 91 14:57:54 GMT References: Distribution: comp Organization: Unisys Corporation, Devon Engineering Offices Lines: 26 In article morse@quark.mpr.ca (Daryl Morse) writes: >[stuff deleted] >Why, then, is there no light-weight mechanism for applications to >communicate with other applications that might happen to be located on >the same system? If I don't want my application to know where it is, >or where the applications that it communicates with are, shouldn't >that be addressed (no pun intended) by the stack? Surely, I shouldn't >be reasonably expected to use X.25, or FDDI, for IPC. (Something >related to this is the lack of a decent performing name service. X.500 >is clearly not a great name service for an RPC.) > >Am I all wet here, and it really isn't the intention of the OSI that >application entities might reside on the same system? Perhaps I'm just >impatient, and these issues will be addressed by the ODP work? My understanding of the intention of OSI (at least a couple of years ago) is to standardize Intersystem communication. Any intrasystem issues were considered private to that system and not to be defined by OSI. This includes layer boundry interfaces. It is not inconsistent for a system to provide a local IPC mechanism which appears the same as the remote IPC mechanism to an application. IMHO, that is the right thing to do. The local mechanisms have not been within the scope of OSI definition. On the other hand, other groups have been working on standardizing local system interfaces and API's, ex. TLI for unix. This work may result in the 'defacto' standards for local 'light weight' mechanisms that you are looking for.