Loading ...
Sorry, an error occurred while loading the content.

4549Re: [rest-discuss] REST for P2P application?

Expand Messages
  • S. Mike Dierken
    Oct 5 10:10 PM
      I'm lost. Perhaps if your applications was re-phrased using 'resource'
      rather than 'node' and 'object' I'd be able to understand.

      > Due to anonymity requirements, the originating node cannot know where all
      > the pieces of an object are (for example, a query or a transaction), and
      > nodes usually cannot know where the object originated.
      What is an 'originating node'? Is that an HTTP client? To hide the location
      of the pieces, you have a single identifiable resource and clients don't
      know what lays beyond.

      > No, different hosts each holding their aspect of distributed objects is
      > integral to the application.
      Okay, but how can you have different hosts holding aspects of a single
      distributed object but not tell any client where those different aspects are
      located??

      > A server hosts multiple nodes that each communicate with many neighbouring
      > nodes ("friends" with which they can exchange IOUs).
      Okay - each 'node' is a resource. Clients communicate with this 'public'
      node. Clients do not know about neighboring nodes. The resource is a type of
      aggregating proxy for those other nodes.

      > Nodes may also communicate with a strange node to pay or receive payment
      from that node.
      Okay - each 'node' may also be a client and can transfer payment to other
      resources or request payment from other resources. In order to receive
      unsolicited transfers, a node needs to have an identifier and the sender of
      payment needs to know what that is.

      > Payments are made by passing IOUs along paths connecting two strange nodes
      in the network of neighbours.
      Ah... a chain of proxies... and this chain is used to obscure the legal
      entity requesting a transfer?




      ----- Original Message -----
      From: "Ryan Fugger" <rfugger@...>
      To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com>
      Sent: Monday, October 04, 2004 11:41 PM
      Subject: Re: [rest-discuss] REST for P2P application?


      > Thanks for the reply. I appreciate the input.
      >
      > On Mon, 4 Oct 2004 22:01:47 -0700, S. Mike Dierken <mdierken@...>
      > wrote:
      >
      > > By 'distributed objects' do you mean an object that has constituent data
      > > that is served by multiple hosts, or do you mean a self-contained object
      > > that has multiple redundant copies on several hosts?
      >
      > Both.
      >
      > > If a single object is resident on several hosts then the single
      > > identifier needs to access a single host that then in turns communicates
      > > with the
      > > disparate constituent servers.
      >
      > Due to anonymity requirements, the originating node cannot know where all
      > the pieces of an object are (for example, a query or a transaction), and
      > nodes usually cannot know where the object originated.
      >
      > > If the several nodes only host redundant copies, then you need a locator
      > > algorithm that satisfies your technical requirements. Do you need to
      > > access the same host several times for performance and only switch hosts
      > > for
      > > reliability in the face of a host failure?
      >
      > No, different hosts each holding their aspect of distributed objects is
      > integral to the application.
      >
      > > It sounds like we should talk about what capabilities a single server is
      > > providing.
      >
      > A server hosts multiple nodes that each communicate with many neighbouring
      > nodes ("friends" with which they can exchange IOUs). Nodes may also
      > communicate with a strange node to pay or receive payment from that node.
      > Payments are made by passing IOUs along paths connecting two strange nodes
      > in the network of neighbours.
      >
      > > You may need a proxy that forwards requests to the current
      > > hosting server, or possibly returns a Location header with the 'new'
      > > location.
      >
      > Since trust is such an integral issue with this application, there must be
      > a mechanism to change any server that proves untrustworthy, including
      > proxy servers. Changing proxy servers then has all the same
      > identifier-renaming problems as changing servers.
      >
      > Like I said, as hard as I've tried to make it work, it just seems that
      > REST is inappropriate for the application. I'm actually looking at
      > bypassing HTTP altogether and using something like Jabber for persistent
      > XML messaging sessions between servers. Very unRESTful, I know, but it
      > would be soooo appealingly simple...
      >
      > Ryan
      >
    • Show all 19 messages in this topic