home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0030.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  2.8 KB  |  55 lines
  1. Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein)
  2.  
  3. People interested in protocol-independent interfaces may also be
  4. interested in UCSPI (ooks-pie), my UNIX Client-Server Program Interface
  5. Standard. It's not a standard, of course, until enough people decide
  6. it's worth using, but it does have implementations for BSD TCP sockets
  7. (with optional RFC 931 support), BSD UNIX-domain sockets (with username
  8. security), and System V named pipes (also with username security), and
  9. I'm working on DECnet and Kerberos v5 implementations. Programs written
  10. for the UCSPI interface will work properly, with no changes, over all of
  11. the above communications systems.
  12.  
  13. Note that the UCSPI interface is much simpler than what I gather POSIX
  14. is looking at standardizing. Basically, you get two file descriptors for
  15. reading and writing to the other side, a protocol-independent record of
  16. who the other side is, and a variable saying what protocol you're using.
  17. It doesn't support any sort of structured data, because that wouldn't be
  18. portable---you can't pass structured data through named pipes. Another
  19. benefit to this hands-off philosophy is that you can use UCSPI from
  20. shell scripts. On the other hand, if you do want to control the
  21. communication at a low level, you can apply protocol-dependent
  22. operations to the descriptors.
  23.  
  24. If UCSPI gains enough momentum, it might be worth making into an
  25. official standard in a few years. Until then, I wonder why POSIX.12 is
  26. trying to impose ``standards'' on an area where the real world has seen
  27. neither successes nor failures. Where are the bad protocol-independent
  28. interfaces in the history books? What do we know about putting good ones
  29. together? Where are all the vendors supporting a protocol-independent
  30. interface? In other words, how does POSIX.12 know it's not going to
  31. settle on a ``standard'' which forever stands in the way of interface
  32. research?
  33.  
  34. If POSIX.12 merely produces a formal specification of how Berkeley and
  35. AT&T already do sockets, then the answer is clear: the industry has come
  36. to a consensus on sockets, people use sockets, and nothing's lost by
  37. stating the obvious. But sockets are not truly protocol-independent, and
  38. from the report I gather that the group aims to create a much more
  39. comprehensive interface. What, pray tell, are they basing their work on?
  40.  
  41. Anyway, I just posted my clientserver package, including UCSPI-91, to
  42. alt.sources. You can also get it from stealth.acf.nyu.edu in
  43. pub/hier/clientserver/*. Please send any comments (or implementations on
  44. top of different protocols) to me at brnstnd@nyu.edu.
  45.  
  46. ---Dan
  47.  
  48. [ I posted this because it contains not only an objection to a POSIX 
  49. document, but a codified alternative.  However, it was iffy; any followups
  50. more concerned with the code than with standards should to go alt.sources.d.
  51. Thanks -- mod ]
  52.  
  53. Volume-Number: Volume 24, Number 31
  54.  
  55.