Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!acorn!osmith From: osmith@acorn.co.uk (Owen Smith) Newsgroups: comp.protocols.iso Subject: Re: ISODE explanation Message-ID: <6236@acorn.co.uk> Date: 4 Apr 91 13:16:04 GMT References: Sender: osmith@acorn.co.uk Distribution: comp Organization: Acorn Computers Ltd, Cambridge, England Lines: 38 In article ARTHUR.RUDOLPH.ART.LAVALLE@OFFICE.WANG.COM (Art LaValle) writes: >Kathy Saint of Hughes Aircraft would like a high level explanation of ISODE >from someone who is familiar with Computer Science. I don't think a Computer >Scientists tutorial on ISODE would be High Level, or what she wants! Has Kathy >read Marshall Rose's book ? If she's looking for a "run of the mill" Software >Developers view of what the "meaning" of what ISODE really is, here's mine: > >ISODE was funded as a means to provide a "free implementation of the OSI refer- >ence model" (particularly the very upper layers). The problem I found wih ISODE version 3 was that it was too poor in quality and functionality to be used in a commercial product. The area I was involved with was ASN.1, trying to use PEPY. PEPY produced enormous code, that repeatedly did the same things. On top of that, the entire X.400 message was dragged into memory in one go, which was a bit of a shame if you were trying to process a message with 32,000 recipients and two 20 mega-byte body parts. The situation is even worse when your process is trying to simultanteously process six different messages. Virtual memory runs out eventually and anyway it is in-efficient compared to the program knowing what it is doing more. So we (Data General) went our own way. We wrote a new ASN.1 compiler which generated memory efficient tables which represented the ASN.1 and what was to be done to it (eg. value passing, pointers to action statement code functions etc.) and then we had the runtime library run over these tables doing the appropriate thing. This resulted in a very considerable (factor of two to three) memory saving over the PEPY generated code, and did not run much slower. We also allowed the programmer to break the message up and process it in bits, leaving the rest of it on disk. This didn't work very well, but it could have been made to work with a bit of a re-design. Please not that I am not trying to belittle the efforts of the people working on ISODE. As something to "get you going" it is very worthwhile, and if ISODE has improved in the areas I have highlighted above since version 3, even better. The views expressed are my own and are not necessarily those of Acorn.