home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / tcpip / ibmpc / 5002 < prev    next >
Encoding:
Text File  |  1992-09-01  |  3.2 KB  |  75 lines
  1. Newsgroups: comp.protocols.tcp-ip.ibmpc
  2. Path: sparky!uunet!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watserv1!steam.uwaterloo.ca!eengelke
  3. From: eengelke@steam.uwaterloo.ca (Erick Engelke)
  4. Subject: Re: tcp-ip library nonblocking I/O (Berkeley compatible)?
  5. Message-ID: <Btx5J4.2tD@watserv1.uwaterloo.ca>
  6. Sender: news@watserv1.uwaterloo.ca
  7. Organization: University of Waterloo
  8. References: <9209011705.AA08725@ftp.com>
  9. Date: Tue, 1 Sep 1992 21:40:16 GMT
  10. Lines: 63
  11.  
  12.  
  13. I wrote:
  14. >>Yes, with one exception.  I believe FTP's PC/TCP does not support the
  15. >>use of select to asynchronously detect the establishment of a connection
  16. >>on a listenning socket.  Someone will surely correct me if I'm wrong.
  17.  
  18. and James (jbvb@ftp.com) corrected it with:
  19. >Unless the code is buggy (and inspection doesn't reveal anything obvious),
  20. >we should report a listening socket with connections available for accept()
  21. >as readable.
  22.  
  23. My confusion came from the fact that FTP's PC/TCP supplies two inteface
  24. layers, one is pretty BSD-ish, the other is certainly more homegrown.
  25. The latter has the select limitation while the BSD-ish one does not.
  26.  
  27. Before anyone interprets this apparently dual API as being a kludge,
  28. let me explain why it exists.  Every DOS based TCP implementation has 
  29. had to deal with the seemingly innumerable problems of fitting everything
  30. into a TSR and dealing with DOS's memory/file services and the lack
  31. thereof.  What does that mean?  They cannot allocate buffers on the
  32. fly, they cannot necessarily do DOS i/o due to the re-entrancy of DOS,
  33. and mapping tcp/ip i/o directly into the filespace (like unix does) 
  34. is possible in part, but not fully.
  35.  
  36. So all the popular TCP systems use a low-level homegrown API to do the
  37. real communication between user applications and the TCP/IP kernel,
  38. but they hide this layer underneath a BSD 4.1 or 4.3-ish set of function
  39. calls.
  40.  
  41. Many products only provide the BSD-ish layer for external developers, 
  42. that encourages them to use only documented facilities and makes the
  43. product look nice so the TCP author doesn't look like he had to make
  44. the kludges that are actually so necessary.  
  45.  
  46. But in doing so, these products force TSR developers to link in 
  47. extra bulky functions, and in the case of at least one library, 
  48. use a malloc(), a definate no-no in tsr development!
  49.  
  50. The solution?  FTP provides their BSD environment (with source which
  51. maps it to their internal api)  and documents their internal API too.  
  52. That tries to make everyone happy.  
  53.  
  54. Their internal API can be called practically any time.  
  55. Compeditors systems which only provide the BSD-ish interface 
  56. can rarely be called during DOS i/o, and sometimes have difficulty
  57. when called during interrupt calls.  
  58.  
  59. I've done TSRs with many of the network stacks, using BSD and
  60. internal APIs.  Here's my advice:
  61.  
  62.     If you are developing a non-TSR: stick to the BSD interface,
  63.     it buys you compatibility.
  64.  
  65.     If you are doing a TSR: use the lowest level interface you
  66.     can find for each vendor's product, and be prepared to do
  67.     a lot of debugging.  Or hire someone else to do the dirty
  68.     work... 
  69.  
  70. Erick
  71. -- 
  72. Erick Engelke                      Engineering Computing
  73.                          University of Waterloo
  74. Waterloo TCP Architect         erick@development.watstar.uwaterloo.ca
  75.