home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / tcpip / ibmpc / 5047 < prev    next >
Encoding:
Text File  |  1992-09-03  |  2.3 KB  |  50 lines
  1. Newsgroups: comp.protocols.tcp-ip.ibmpc
  2. Path: sparky!uunet!microsoft!hexnut!alistair
  3. From: alistair@microsoft.com (Alistair Banks)
  4. Subject: Re: Named Pipes
  5. Message-ID: <1992Sep04.024349.13389@microsoft.com>
  6. Date: 04 Sep 92 02:43:49 GMT
  7. Organization: Microsoft Corporation
  8. References: <9209021556.AA06310@ftp.com>
  9. Lines: 39
  10.  
  11. In article <9209021556.AA06310@ftp.com> jbvb@ftp.com writes:
  12. >
  13. >    .... Still, this leaves the question, where are the RFC 1001/2 equivalents
  14. >    for doing Named Pipes on TCP/UDP? Not worth the effort??
  15. >
  16. >My personal opinion (which may be from way out in left field, since I've
  17. >not done any actual named-pipes applications) is based on my understanding
  18. >that Microsoft based named pipes on a Netbios-style flat namespace, with
  19. >broadcast name defense implied.  This works badly in an internetworking
  20. >environment, just like Netbios.  I think you can run at least some
  21. >named-pipes applications with a glue layer that thranslates to Netbios calls,
  22. >and that appears to be satisfying whatever demand there is...
  23.  
  24. The NamedPipe semantics don't assume flat namespace - they're simply an
  25. IPC mechanism with a namespace that's part of the filesystem namespace. In
  26. LanMan for OS/2 & MS-Dos they were based on the SMB protocol on top of
  27. Netbios, but Novell implemented the same NamedPipe APIs to their SPX
  28. protocol, and Banyan to Vines.
  29.  
  30. NamedPipes are only "another" high level, convenient IPC mechanism. The
  31. advantage in  the LanMan implementation, was that being implemented on
  32. top of SMB, they were authenticated in the same way as file access
  33.  
  34. A major disadavantage in both MS-DOs & OS/2 implementations is that the
  35. NamedPipe services are supplied by a single .dll, which makes the
  36. co-residence of multiple implementations very hard
  37.  
  38. In Windows NT, NamedPipe services are provided by a FileSystem driver, like
  39. any other file system driver, so while the SMB-based/LanManager NamedPipes
  40. are built in, its hoped that the Novell/SPX and Banyan/Vines versions will
  41. co-exist. It would probably be possible to implement NamedPipes with some
  42. glue onto tcp/ip in the same style as Novell & Banyan
  43.  
  44. I'm not about to enter into "the universal IPC mechanism" debate! NamedPipes
  45. is just another pretty convenient one, from my point of view, if you dont
  46. implement it on top of a secure protocol (and of course MailSlots is the
  47. datagram partner API to session-based NamedPipes)
  48.  
  49. -- Alistair 
  50.