home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / protocol / iso / 1432 < prev    next >
Encoding:
Internet Message Format  |  1992-12-17  |  3.8 KB
  1. Path: sparky!uunet!spool.mu.edu!yale.edu!ira.uka.de!fauern!uni-erlangen.de!not-for-mail
  2. From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
  3. Newsgroups: comp.protocols.iso
  4. Subject: Re: OSI and standard modules (like packet) ?
  5. Date: 17 Dec 1992 17:41:02 +0100
  6. Organization: Regionales Rechenzentrum Erlangen
  7. Message-ID: <1gqaiuEINNhdo@uni-erlangen.de>
  8. References: <unikjtf.44.0@uts.uni-c.dk>
  9. Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
  10. NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de
  11. Lines: 67
  12.  
  13. unikjtf@uts.uni-c.dk (Jan Ferre') writes:
  14.  
  15. >I'm missing OSI in real life!
  16.  
  17. So do I!
  18.  
  19. >Now here's my proposal: Why not define a set of interfaces for specific 
  20. >computerseries and especially for specific operating systems in order to 
  21. >ease PD programmers to get started. I suggest something like:
  22. >   Interface to TP is done via device OSITP on DOS.
  23. >   Packets to the interface are submitted as struct { bla bla bla } and the 
  24. >   results will be returned as struct {blu blu blu}.
  25.  
  26. Excellent idea! Why don't you start writing a proposal, post it here,
  27. then we'll discuss it and then we'll see whether anyone wants to
  28. write a demo implementation.
  29.  
  30. Using C structs as the API specification might not be a good idea under DOS.
  31. Different compilers might produce different memory layouts and it should not
  32. be necessary to use the same compiler for the TSR driver and the application.
  33.  
  34. >It should be possible to identify several 'cuts' in the 7 layer model - in 
  35. >fact a cut is needed at least for every possible split possibility: In the 
  36. >Nordic Government OSI Profile there should be a cut to provide for 8802-3 
  37. >and -5, a cut to provide for 8878 as contrast to 8473, a cut for 8073, and a 
  38. >cut in 8650 to provide interface for the different layer 7 applications.
  39.  
  40. I would suggest only 2 cuts: one cut near the network layer and
  41. one cut that offers ACSE, RTSE and ROSE to the higher layers together
  42. with BER/PER/... parsing service (that's what application programmers need if
  43. they want to implement a FTAM client prototype within a few days.)
  44. The cut within the network layer need not necessarily be one of the
  45. cuts in the OSI RM. The module below the near-network-cut should
  46. contain the network specific software (e.g. an async HDLC/X.25 driver
  47. for COM1 and COM2, an CLNP driver over a packer driver, a 'for further
  48. study' CONS module using AX.25, etc.). The module between the two cuts
  49. would perform all the OSI protocol machinery (from transport to ROSE)
  50. in which both the network and the application programmer aren't very 
  51. interessted.
  52.  
  53. Under MS-DOS an machine-level API and a standard C++ interface for the higher
  54. cut might motivate a lot of PD programmers to implement interesting
  55. applications without having to worry about the details of layer 4-6.5.
  56.  
  57. >Now whats wrong with the standards themselves? Simply that they don't 
  58. >provide the information needed to ship binary modules that the users can mix.
  59.  
  60. >My dream (let's call it a wish for christmas) is to go to SIMTEL to get 
  61. >layer 1,3,5, to buy layer 2 and 7 from IBM and to buy layer 6 and 4 from 
  62. >Nonsence-soft in Yougoslavia. Or at least to be able to get hold of 
  63. >resonable modules from different sources.
  64.  
  65. Perhaps a seperate module for each OSI RM layer isn't even necessary.
  66. Developing nice APIs is a lot of work, so let's concentrate on a few only!
  67.  
  68. If enough people come together, I might find some time to implement
  69. a below-network API TSR module for async HDLC and X.25. The prototype is 
  70. already available, I still don't have a nice API and I don't want to 
  71. construct my own API.
  72.  
  73. Markus
  74.  
  75. -- 
  76. Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
  77. Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
  78. ----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
  79. ---- simply not getting the most out of life possible. (Brian Downing) ----
  80.