home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / iso / 1445 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  4.2 KB
  1. Path: sparky!uunet!gatech!darwin.sura.net!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: 22 Dec 1992 16:12:09 +0100
  6. Organization: Regionales Rechenzentrum Erlangen
  7. Message-ID: <1h7b89EINNrvm@uni-erlangen.de>
  8. References: <unikjtf.44.0@uts.uni-c.dk> <1gqaiuEINNhdo@uni-erlangen.de> <1h6qdjINNmhj@bnsgd245.bnr.co.uk>
  9. Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
  10. NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de
  11. Lines: 72
  12.  
  13. iann@bnr.co.uk (Ian Newman) writes:
  14.  
  15. >What is the difference between what you're planning to propose and what AT&T's
  16. >TLI (Transport Library Interface) does for you at Transport Layer?
  17.  
  18. MS-DOS is not UNIX. MS-DOS has highly specific demands for interprocess
  19. communication. Interfaces have to be defined at the memory layout level
  20. and there are a LOT of restrictions (just remember the various 64kB
  21. barriers in the addressing model) that have to be considered in the
  22. interface design. So we can learn much more from established DOS
  23. interfaces (e.g. packed drivers, NDIS, ...) than from the UNIX world.
  24.  
  25. TLI is just a collection of C functions that you can call. This is far from
  26. all we need under MS-DOS.
  27.  
  28. Why don't I suggest to use a TLI mapping for the lower interface/cut?
  29. Well:
  30.  
  31. My suggested architecture has 3 modules:
  32.  
  33.     1. network driver
  34.     2. OSI driver
  35.     3. application programm
  36.  
  37. Now let me define the meaning of these 3 modules. Let's begin with the
  38. OSI driver. It is indented to be written only once and it should include
  39. all the boring stuff that is independent from the lower layers and the
  40. application. This includes at least session, presentation and ACSE. I
  41. believe, that it includes also transport, part's of the network layer
  42. and parts of ROSE, RTSE and BER en-/decoding. The OSI driver should include
  43. all things that we want to develop only once.
  44.  
  45. A network driver will be necessary for each kind of lower layer stack
  46. that we want to use (e.g. CLNP over Ethernet, CONS over Ethernet,
  47. CONS with async X.25 over serial lines, ...). As much common functionality
  48. as possible should be concentrated in the OSI driver, so TP0-TP4 (which
  49. use all the same basic header format etc.) clearly belongs not in the
  50. network driver. Also the code that decides which of several loaded network
  51. drivers (e.g. serial line and ethernet) should be used has to be located
  52. outside the network driver. Consequently TLI is the wrong place to start
  53. with. The network driver/OSI driver interface has to be specified from the
  54. network drivers point of view.
  55.  
  56. Both the network and the OSI drivershould be implemented as device
  57. drivers (started in CONFIG.SYS) or as TSR programs. This avoids complicated
  58. linking and makes them easy to exchange. Most other DOS networking software
  59. that I know uses a very similar approach. Many network drivers will use even
  60. another driver below (e.g. packet, FOSSIL) to access the hardware. All this 
  61. will make development of applications and network drivers very easy.
  62.  
  63. Perhaps the term OSI driver should be replaced by a better name, as not the
  64. full functionality of a 7 layer stack is implemented in this programm. E.g., 
  65. many parts of the service specific application layer service elements (e.g.
  66. MTS in X.400, etc.) will be part of the application program.
  67.  
  68. The interface between the OSI driver and the application program (e.g.
  69. an X.500 user agent) might very well be based on something developped
  70. for UNIX, at least if you use a common C library in order to access
  71. the OSI driver. This is a real API (an interface designed from the 
  72. application's point-of-view, not from the driver's) that should provide
  73. the functionality (service) of ACSE, ROSE, ... It should be designed,
  74. so that demo examples that use full ACSE, ROSE, BER etc. might be written with
  75. less then 100 lines. This is surely possible and will be very impressive
  76. for other public domain and commercial authors.
  77.  
  78. Markus
  79.  
  80. -- 
  81. Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
  82. Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
  83. ----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
  84. ---- simply not getting the most out of life possible. (Brian Downing) ----
  85.