home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / dcom / cellrel / 920 < prev    next >
Encoding:
Text File  |  1992-12-24  |  2.8 KB  |  61 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!pacbell.com!unet!trappist!earlf
  3. From: earlf@trappist.net.com (Earl Ferguson Adv Dev)
  4. Subject: Re: Path Building
  5. Message-ID: <1992Dec24.045318.18879@unet.net.com>
  6. Sender: news@unet.net.com
  7. Nntp-Posting-Host: trappist
  8. Organization: Network Equipment Technologies
  9. References: <1992Dec17.211811.6553@iscnvx.lmsc.lockheed.com>
  10. Date: Thu, 24 Dec 1992 04:53:18 GMT
  11. Lines: 48
  12.  
  13. In article <1992Dec17.211811.6553@iscnvx.lmsc.lockheed.com> myoung@force.ssd.lmsc.lockheed.com writes:
  14. >OK, I have a problem here:
  15. >
  16. >  I am a migrating process, and am currently sitting at memory
  17. >associated with a file containing objects of a certain class.
  18. >I have arrived here via a series of exploratory hops from data node 
  19. >to data node, moving at each step when the local data met some
  20. >condition (I am a query moving through data).
  21. >
  22. >  Now, having found the data I desire, I want to link this data directly
  23. >back to the location in memory where I started, thus building a memory
  24. >to memory VCI to satisfy my query.  ...
  25. >
  26. >  Problem:  I want to traverse back over my path,
  27. Sounds like token ring source routing philosophy. Each exploratory hop
  28. adds its identification so that the return path can be examined. The
  29. return link is merely a traverse of the established path in reverse.
  30.  
  31. >closing out any
  32. >loops appearing along the way back, possibly performing some local
  33. >optimization between hops looking for shorter paths.  This backward
  34. >path I traverse, takes me back through switches, processors, and files
  35. >contained at processors, updating the virtual path along the way.
  36. >
  37. >  Don't tell me that a hidden hand in the network management will do this
  38. >for me, as that just begs the question.
  39. Optimizing the return path requires some knowledge of the topology
  40. traversed beyond that that will be found in merely recording the forward
  41. path. Thus access to the topology data base (be it via network
  42. management or some generaly accessible topology server) and the path
  43. cost information (and desired COS/QOS, etc.) is all required.
  44.  
  45. This doesn't sound like a networking issue as much as it is an
  46. application level issue, since there are factors that go well beyond the
  47. network layer that may need to be considered (e.g. if the data is
  48. replicated for security/backup, there are probably 2 or more possible
  49. results to the search, resulting in the need to further qualify which
  50. will be used - shortest, fastest, most reliable - and possibly
  51. coordinated with the results of previous searches and even possibly
  52. future searches [or simultaneous]. The decision perhaps needs to be made
  53. at the source based on the results of all other searches that should be
  54. coordinated in order to reduce queueing and synchronizing
  55. requirements.).
  56.  
  57. ---
  58. Earl Ferguson
  59. earlf@net.com
  60. My personal opinions and NOT those of my employer.
  61.