home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / networks / tcpip / multinet / 2068 < prev    next >
Encoding:
Text File  |  1992-08-30  |  2.0 KB  |  41 lines
  1. Newsgroups: vmsnet.networks.tcp-ip.multinet
  2. Path: sparky!uunet!mcsun!sunic!sejnet.sunet.se!eric
  3. From: eric@sejnet.sunet.se (Eric Thomas)
  4. Subject: Re: Do UCX and Multinet support nonblocking I/O?
  5. Message-ID: <1992Aug31.024421.1@sejnet.sunet.se>
  6. Lines: 28
  7. Sender: news@sunic.sunet.se
  8. Reply-To: ERIC@SEARN.SUNET.SE
  9. Organization: SUNET, Stockholm, Sweden
  10. References: <dank.715215744@blacks>
  11. Date: Mon, 31 Aug 1992 02:44:21 GMT
  12.  
  13. In article <dank.715215744@blacks>, dank@blacks.jpl.nasa.gov (Daniel R. Kegel) writes:
  14. > Hi,
  15. > I want to port to VMS a Unix program which initiates several
  16. > connections to TCP servers and uses nonblocking I/O
  17. > to manage all the connections simultaneously.
  18.  
  19. Porting unix socket-based code to VMS is easy (at least with Multinet), it
  20. mostly compiles the first time and making it work is just a matter of replacing
  21. the many system("rm logfile") with more appropriate calls. Finding out that it
  22. doesn't quite perform as well as similar native VMS utilities is the bad
  23. surprise. Realizing that the VMS-ported server isn't slower than the native
  24. unix one only takes a minute or so, and deciding to do something about it is a
  25. matter of seconds if, like me, you cannot stand things which are unnecessarily
  26. slow.
  27.  
  28. Changing the server to use asynchronous calls everywhere is easy and solves the
  29. problem admirably (again with Multinet, and assuming you are familiar with
  30. AST's). The difficulty is convincing unix people who are impressed with the
  31. performance of your server on that despicable little 2 mipser and would like a
  32. copy of your code that this cannot be done under unix. Just sending them the
  33. code won't work, because they will come back 10ms later with questions about
  34. all this IO$_ crap. Explaining takes time and usually results in religious
  35. statements about why Things should not be done that way, which is precisely why
  36. it can't be done with unix. Eventually you will wish you had just put up with
  37. the slow response time instead of trying to prove to the world that things
  38. don't have to be that slow - my advice ;-)
  39.  
  40.   Eric
  41.