home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / os2 / advocacy / 12122 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  5.2 KB

  1. Xref: sparky comp.os.os2.advocacy:12122 comp.os.os2.networking:2688
  2. Newsgroups: comp.os.os2.advocacy,comp.os.os2.networking
  3. Path: sparky!uunet!caen!zaphod.mps.ohio-state.edu!rpi!assela
  4. From: assela@marcus.its.rpi.edu (A. Andre Asselin)
  5. Subject: Re: ibm tcp/ip a ripoff?
  6. Message-ID: <l2-3tbd@rpi.edu>
  7. Nntp-Posting-Host: marcus.its.rpi.edu
  8. References: <1iratf$aqq@agate.berkeley.edu> <C0q258.JK5@watserv1.uwaterloo.ca>
  9. Date: Tue, 12 Jan 1993 16:25:54 GMT
  10. Lines: 100
  11.  
  12. eengelke@sail.uwaterloo.ca (Erick Engelke) writes:
  13. >In article <1iratf$aqq@agate.berkeley.edu> jp1ek@sunc.shef.ac.uk writes:
  14. >>i am beginning to think ibm tcp/ip is a rip off.  my comparative
  15. >>reference is the wattcp freeware tcp/ip for msdos and tcp/ip for
  16. >>xenix.
  17.  
  18. >As the author of the cheaper one you mention, here are some
  19. >observations and comments.
  20.  
  21. As a former co-op in IBM's TCP/IP development, here are mine...
  22.  
  23. >>c) few ethernet cards supported (compared to wattcp with clarkson
  24. >>packet drivers);
  25. >Clarkson and later CRYNWR packet drivers have served wonderfully
  26. >over the years.  But probably one of the greatest contributions
  27. >was Russ's skeleton which allowed anyone to write a decent driver
  28. >for any new hardware they encounterred.  
  29.  
  30. >To my knowledge, there is no NDIS driver freely available in source 
  31. >code for either DOS or OS/2.  From my warped view that makes it seem
  32. >like every hardware manufacturer has to either contract an overpriced
  33. >NDIS writing team or learn the hard way.
  34.  
  35. >And the configuration is pretty gruesome.  I find this true of
  36. >all NDIS installations, who decided we didn't mind rebooting
  37. >20 times and manually editing scripts just to get the configuration 
  38. >right or if we want to try someone else's TCP.
  39.  
  40. >I can run DOS based ODI and Packet Drivers fine under DOS VDMs,
  41. >but my 3c507 NDIS driver kills my modem, go figure!
  42.  
  43. NDIS is the standard network adapter interface under DOS, OS/2 and now Windows
  44. NT.  There are MANY NDIS drivers available for the various cards, and surely
  45. more to follow, since this is one area that IBM and Microsoft agree in!
  46. As far as setup goes, have you ever tried NTS/2 (also called LAPS)?  It's
  47. cake.  Click on your adapter, click on your protocol, and bang, you're done.
  48. Very easy.
  49.  
  50. >>d) common tcp/ip programmes not or badly implemented (rsh does
  51. >>not accept piped input or properly return stdout from the
  52. >>executed command; ftp does not implement piped input/output for
  53. >>get and put commands; etc).
  54. >I wouldn't want to brag here because most of the free apps I
  55. >distribute are pretty haphazzard.  My contribution was more
  56. >a small TCP stack suitable for inclusion into other's programs, 
  57. >like Kermit, WAIS, various 3270 emulation TSRs, several commercial 
  58. >TCP applications, and embedded systems. 
  59.  
  60. >But I too have found the IBM supplied apps very crude and
  61. >often broken (worst VT100/220 emulator I've seen, TELNETD
  62. >crashes much more frequently and is less responsive than my own
  63. >running under DOS!)
  64.  
  65. I can't vouch for what you're seeing on your machine, but as far as I'm
  66. concerned, I've never had a problem with any of the Telnet clients getting
  67. into my campus UNIX computers...
  68.  
  69. >>i) hard to setup (xenix tcp/ip took me about three hours from
  70. >>openning the box to a reliable anonymous ftp service; wattcp took
  71. >>about an hour from loading to basic operation; with os2, i'm
  72. >>still at it weeks later).
  73.  
  74. >The reason why WATTCP, NCSA, CUTCP, KERMIT and most other free TCPs
  75. >are so easily configured is simple - we authors don't want people 
  76. >calling us asking how to get the software working and we don't
  77. >want to have to document much - hence simple software.
  78.  
  79. >You might want to note that all the free software use ASCII config
  80. >files, support some way to do include files so multi-station 
  81. >installs are simple, easily support BOOTP, and seem to need
  82. >comparatively little documentation to get you rolling.  This
  83. >is not a boast but a reminder that TCP installation does not
  84. >need to be the pain that it is under IBM's lable.
  85.  
  86. >Most commercial houses would do well to take a look at getting
  87. >back to basics and putting the emphasis on the software and 
  88. >ease of installation/use.
  89.  
  90. I'm afraid that I don't agree with you.  ICAT is a very easy to use
  91. installation tool.  If you're setting up your own workstation, you're never
  92. going to be able to get away from having to know SOMETHING about TCP/IP and
  93. how your network is configured.  ICAT minimizes what you have to know and
  94. organizes the information well.  It's certainly WORLDS better than what I've
  95. seen on most UNIXs.  (BTW, if they can help it, IBM would prefer that you
  96. didn't have to call them either to install software-- don't forget, every
  97. one of those calls costs $$$).
  98.  
  99. >From a programmer's standpoint, I think IBM made a big mistake
  100. >in their approach to reading/writing data to the tcp connection.
  101. >Under OS/2 you quickly find that pipes, shared memory, 
  102. >semaphores, queues, everything else maps wonderfully into the
  103. >filesystem except TCP.  Do Novell's, FTP's, Essex's or anyone
  104. >else's TCPs provide this support?  Everything else about OS/2
  105. >makes BSD code relatively simple to support except TCP, someone 
  106. >really goofed up IMHO.
  107.  
  108. That's true enough, and I agree with you that it'd be better if sockets
  109. were integrated into the file system.
  110.  
  111.      - Andre Asselin (assela@rpi.edu)
  112.