home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / cellrel / 436 < prev    next >
Encoding:
Text File  |  1992-08-31  |  2.6 KB  |  58 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!stanford.edu!kronos.arc.nasa.gov!iscnvx!news
  3. From: bantha.decnet.lockheed.com!young
  4. Subject: Re: Another Problem
  5. Message-ID: <1992Aug31.160529.8597@iscnvx.lmsc.lockheed.com>
  6. Reply-To: young@bantha.decnet.lockheed.com
  7. Sender: news@iscnvx.lmsc.lockheed.com (News)
  8. Organization: LMSC, Sunnyvale, California
  9. References: <1992Aug30.164226.2031@iscnvx.lmsc.lockheed.com>,<p8bpe4o@rhyolite.wpd.sgi.com>
  10. Date: Mon, 31 Aug 92 16:05:29 GMT
  11. Lines: 45
  12.  
  13. In article <p8bpe4o@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  14. >In article <1992Aug30.164226.2031@iscnvx.lmsc.lockheed.com>, bantha.decnet.lockheed.com!young writes:
  15. >> This newsgroup continues to debate the interface between TCP/IP routers
  16. >> and ATM. Must be an important application.
  17. >> 
  18. >> Now here is another problem which ATM might solve.
  19. >> 
  20. >> As I look around this company I see hundreds of little cubic foot computers
  21. >> on each desktop, exactly alike, distributed geographically.  Some companies
  22. >> literally have thousands of these things.
  23. >> 
  24. >> Imagine that an account executive wants to read into his spread sheet the
  25. >> entire daily summary of mail orders spread over a number of distributed
  26. >> offices.  Thus, he wants to extract a particular file located in each of
  27. >> a large set of desktop machines.  
  28. >> 
  29. >
  30. >Are you sure that ATM is an obvious part of a solution to this kind of
  31. >problem?
  32. >
  33. >Wouldn't a naive ATM based solution involve setting up virtual circuits
  34. >to each of the target machines, some fixed number at a time, probably
  35. >one, with the consequent terrible response times?  And wouldn't a naive
  36. >ATM based system involve a lot of manual configuring?
  37. >
  38. >Doesn't this sound more like an application for a multicast based
  39. >"distributed" application?  Perhaps some kind of multicast remote
  40. >procedure call?  Using UDP/IP multicast?
  41. >
  42. >That is not to say that the layers below UDP/IP might not involve one
  43. >or more wide area or local ATM circuits.
  44. >
  45. >
  46. >Vernon Schryver,  vjs@sgi.com
  47. Yes, Yes the solution needs some kind of exploratory, application specific,
  48. protocol which can search out and find, then bind those desktops in
  49. a spanning tree, and then have the capacity to extract file data from
  50. each node, all in a parallel fashion.
  51.  
  52. Does ATM help?  Yes, if the vpi/vci are not naive.  The intelligent
  53. messaging system performs best when it has a virtual "graph machine" below
  54. it on which it can build its tracks, tear them down, tunnel about etc.
  55. The problem is not that ATM virtual paths are naive, the problem is that
  56. the ATM architecture does not postulate a simple "bios" for path building
  57. and network exploration.
  58.