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

RE: [decentralization] uServ project

Expand Messages
  • Lucas Gonze
    uServ has some really cool things. Addressing piggybacked on email: A generic problem is how to get IP addresses for peers. There are a billion approaches.
    Message 1 of 12 , Dec 1, 2001
    • 0 Attachment
      uServ has some really cool things.

      Addressing piggybacked on email:
      A generic problem is how to get IP addresses for peers. There are a billion
      approaches. One of these approaches is consistent hashing. In consistent
      hashing you have a hash function that converts a known datum, like the name of a
      file, to an IP address. All consistent hashing schemes I know of use a mesh.
      uServ has a rule for hashing email addresses to IP addresses instead. Pretty
      neat.

      Buddy services:
      Nodes can team up to proxy for one another.
      Nodes can mirror one another's content.

      An interesting thing about buddy services is that they can work either between
      friends or between owners of two machines with different capabilities, like a
      laptop and a desktop machine.

      > -----Original Message-----
      > From: bert@... [mailto:bert@...]
      > Sent: Friday, November 30, 2001 9:52 PM
      > To: decentralization@yahoogroups.com
      > Subject: [decentralization] uServ project
      >
      >
      > uServ is a project at IBM which exploits P2P techniques to provide a
      > reasonable alternative to paid web hosting services for a wide class of
      > users.
      >
      > While you can't (yet) use it unless you have IBM intranet access, we've
      > made a research report available describing our internal deployment and
      > the technical details of the system.
      >
      > http://www.almaden.ibm.com/cs/people/bayardo/userv/
      >
      > Hope you find it interesting.
      >
      >
      >
      > To unsubscribe from this group, send an email to:
      > decentralization-unsubscribe@egroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
      >
    • rahul@reno.cis.upenn.edu
      Lucas, It would be better, IMHO, to reverse adressing. That is, email piggybacking on domain, and would provide a business opportunity for someone. The idea is
      Message 2 of 12 , Dec 2, 2001
      • 0 Attachment
        Lucas,
        It would be better, IMHO, to reverse adressing. That is, email
        piggybacking on domain, and would provide a business opportunity for
        someone. The idea is simply to fix a domain, like nareau.net, and in
        userv style, do a rahul.nareau.net (actually, even better do a global
        [uuid].nareau.net where [uuid] maps to rahul in some local scope)

        Now do home@..., work@....
        Pointing to appropriate spheres of usage..
        The MX and SRV records
        could be appropriately pointed for email, web, gnutella, jabber-based
        on presence, using dynamic dns capabilities in bind 9.
        So mail would be forwarded(semi permanent), and web like stuff could be
        changed on demand..
        Rahul

        >
        > uServ has some really cool things.
        >
        > Addressing piggybacked on email:
        > A generic problem is how to get IP addresses for peers. There are a billion
        > approaches. One of these approaches is consistent hashing. In consistent
        > hashing you have a hash function that converts a known datum, like the name of a
        > file, to an IP address. All consistent hashing schemes I know of use a mesh.
        > uServ has a rule for hashing email addresses to IP addresses instead. Pretty
        > neat.
        >
        > Buddy services:
        > Nodes can team up to proxy for one another.
        > Nodes can mirror one another's content.
        >
        > An interesting thing about buddy services is that they can work either between
        > friends or between owners of two machines with different capabilities, like a
        > laptop and a desktop machine.
        >
        > > -----Original Message-----
        > > From: bert@... [mailto:bert@...]
        > > Sent: Friday, November 30, 2001 9:52 PM
        > > To: decentralization@yahoogroups.com
        > > Subject: [decentralization] uServ project
        > >
        > >
        > > uServ is a project at IBM which exploits P2P techniques to provide a
        > > reasonable alternative to paid web hosting services for a wide class of
        > > users.
        > >
        > > While you can't (yet) use it unless you have IBM intranet access, we've
        > > made a research report available describing our internal deployment and
        > > the technical details of the system.
        > >
        > > http://www.almaden.ibm.com/cs/people/bayardo/userv/
        > >
        > > Hope you find it interesting.
        > >
        > >
        > >
        > > To unsubscribe from this group, send an email to:
        > > decentralization-unsubscribe@egroups.com
        > >
        > >
        > >
        > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        > >
        > >
        > >
        >
        >
        > To unsubscribe from this group, send an email to:
        > decentralization-unsubscribe@egroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
      • Hugh Pyle
        Very interesting. One comment - What measures are in place to secure the system against spoofing (eg. of the replica or proxy function)? Although you
        Message 3 of 12 , Dec 3, 2001
        • 0 Attachment
          Very interesting.  One comment -

          What measures are in place to secure the system against spoofing (eg. of the "replica" or "proxy" function)?  Although you discuss security in the paper, a major attack point not discussed would be to trick the controller into believing that your target is offline or firewalled and that you are their proxy.

          > uServ is a project at IBM which exploits P2P techniques to provide a
          > reasonable alternative to paid web hosting services for a wide class of
          > users.

          -Hugh
        • Bill Kearney
          ... Well, changed at the rate of current DNS propogation settings. If you moved your target server to a different IP address the external users wouldn t
          Message 4 of 12 , Dec 3, 2001
          • 0 Attachment
            > Pointing to appropriate spheres of usage.. The MX and SRV records
            > could be appropriately pointed for email, web, gnutella,
            > jabber-based on presence, using dynamic dns capabilities in bind 9.
            > So mail would be forwarded(semi permanent), and web like
            > stuff could be changed on demand..

            Well, changed at the rate of current DNS propogation settings. If
            you moved your 'target server' to a different IP address
            the 'external' users wouldn't know about it until their DNS cache
            expired and that's supposed to be based on your domain's TTL value.

            Also, mail MX records are 'supposed' to not use CNAME records.

            My point is that this IS being done currently with SRV records and
            more folks might want to start looking at doing it with their own
            products.

            Microsoft's Exchange Instant Messaging does this using RVP SRV
            records. Some links:
            http://support.microsoft.com/default.aspx?scid=kb;EN-US;q266643
            http://www.microsoft.com/technet/treeview/default.asp?
            url=/TechNet/prodtechnol/exchange/proddocs/ex2kplan/c11inst.asp


            DNS SRV Record

            Instant Messaging uses a DNS service location resource (SRV) record
            to identify the host names for other services. For example, suppose
            Bob in the microsoft.com domain wants to use Instant Messaging to
            communicate with a colleague whose e-mail address is salman@....
            Bob adds the SMTP address salman@... to his Instant Messaging
            contact list. Bob's client performs an SRV lookup at the msft.com DNS
            zone for the RVP service, and learns that the host for Instant
            Messaging Service in this zone is im.msft.com. Bob's client then
            constructs the Instant Messaging URL
            http://im.msft.com/instmsg/aliases/salman. In this way, Instant
            Messaging uses the SRV record to construct an Instant Messaging
            address from an e-mail address.

            One of the only things stopping the wider use of this concept is the
            lack of support in the clients. If you write a client, give pause to
            using SRV records. It's not perfect, by any means, but it's worth
            considering.

            -Bill Kearney
          • rahul@reno.cis.upenn.edu
            So if I understood right, using SRV could be done even for the email, and SRV s could be maintained with a smaller TTL? The original reason for wanting to
            Message 5 of 12 , Dec 3, 2001
            • 0 Attachment
              So if I understood right, using SRV could be done even for the email,
              and SRV's could be maintained with a smaller TTL?

              The original reason for wanting to invert what the userv guys did was
              outages like the @home one. Or people leaving jobs and such.., I'm
              guessing that things wouldnt change that often. Even better is to use
              personal hub systems, and use the IM notion of presence to a personal
              hub for temporary login to a mostly unchanging system.
              (Personal hub system is something like the E21 in Dertouzo's The
              Unfinished revolution..basically a personal internet router and content
              keeper, much like userv, but multiprotocol)
              Rahul
              >
              > One of the only things stopping the wider use of this concept is the
              > lack of support in the clients. If you write a client, give pause to
              > using SRV records. It's not perfect, by any means, but it's worth
              > considering.
              >
              > -Bill Kearney
              >
              >
              >
              > To unsubscribe from this group, send an email to:
              > decentralization-unsubscribe@egroups.com
              >
              >
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              >
              >
            • bert@akamail.com
              During uServ login, a client provides an authenticating password, after which a unique cookie is assigned to establish a session. This cookie has to be
              Message 6 of 12 , Dec 3, 2001
              • 0 Attachment
                During uServ login, a client provides an authenticating password, after
                which a unique "cookie" is assigned to establish a session. This cookie
                has to be presented to the coordinator with the appropriate instructions

                by a client before the coordinator will activate any proxy to accept
                connections on its behalf. Similarly, the coordinator will only activate

                replicas for which the client has listed as authorized replicas for his
                site. So there is no way for another client to spoof being a proxy or
                replica unless they've sniffed the client's session cookie or stolen the

                client's password.

                Roberto

                Hugh Pyle wrote:

                >
                > Very interesting. One comment -
                >
                > What measures are in place to secure the system against spoofing (eg.
                > of the "replica" or "proxy" function)? Although you discuss security
                > in the paper, a major attack point not discussed would be to trick the
                > controller into believing that your target is offline or firewalled
                > and that you are their proxy.
                >
                > > uServ is a project at IBM which exploits P2P techniques to provide a
                >
                > > reasonable alternative to paid web hosting services for a wide class
                > of
                > > users.
                >
                > -Hugh
                >
                > To unsubscribe from this group, send an email to:
                > decentralization-unsubscribe@egroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
              • Lucas Gonze
                ... yeah, I think the TTL is quite small -- two minutes.
                Message 7 of 12 , Dec 3, 2001
                • 0 Attachment
                  per Rahul:
                  > So if I understood right, using SRV could be done even for the email,
                  > and SRV's could be maintained with a smaller TTL?

                  yeah, I think the TTL is quite small -- two minutes.
                • rahul@reno.cis.upenn.edu
                  ... More generally, the TTL could be linked to presence time, or in more kerberos like language, ticket duration, right? Why would this be useful? Well
                  Message 8 of 12 , Dec 3, 2001
                  • 0 Attachment
                    >
                    > per Rahul:
                    > > So if I understood right, using SRV could be done even for the email,
                    > > and SRV's could be maintained with a smaller TTL?
                    >
                    > yeah, I think the TTL is quite small -- two minutes.
                    >
                    More generally, the TTL could be linked to presence time, or in more
                    kerberos like language, ticket duration, right? Why would this be
                    useful? Well consider a personal server on my desktop at work, and a
                    corresponding relayer/backupper/content-cacher at the office firewall.
                    Essentially I want that firewall machine to maintain a DNS SRV for me
                    which punts to my desktop machine when I am on, for certain services
                    only. So, I may want jabber to go through to the desktop, but web
                    requests to go to the firewall machine only, if they are from the
                    general public, but if they are from a 'shared space' of members of this
                    group, I'd want to serve from desktop, as long as I am there.
                    Ofcourse, the policy could reflect organization firewall policy as
                    well..

                    Thus, one would want a DNS TTL related to ticket time in some fashion to
                    eliminate multiple lookups, and further, overload the local meaning of
                    the service field to enable only some say web requests to go in while
                    others go elsewhere..or do that endpoint resolution in the name itself..
                    Rahul
                    >
                    > To unsubscribe from this group, send an email to:
                    > decentralization-unsubscribe@egroups.com
                    >
                    >
                    >
                    > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                    >
                    >
                  • rahul@reno.cis.upenn.edu
                    On a related note, http://www.purl.org/ maintains a persistent URL framework, used much by the RDF community for XML namespaces. What about DNS names? Services
                    Message 9 of 12 , Dec 3, 2001
                    • 0 Attachment
                      On a related note,
                      http://www.purl.org/
                      maintains a persistent URL framework, used much by the RDF community for
                      XML namespaces.
                      What about DNS names?
                      Services like dyndns already provide such domain services very cheap
                      or free. The challenge would be to create organizations like purl that
                      would provide such survices tursworthily and permanently, that is so
                      that such servers could establish trust relationships
                      (b.almaden.ibm.com = work.b.nareau.net), and be trusted not to
                      arbitrarily blink like @home, or if they do, devolve to other servers in
                      the network.

                      Secondly, every personal hub could have its own DNS to completely
                      eliminate central naming if desired. So each could have its own local
                      namespace for resources through the DNS system.
                      Rahul
                      >
                      > >
                      > > per Rahul:
                      > > > So if I understood right, using SRV could be done even for the email,
                      > > > and SRV's could be maintained with a smaller TTL?
                      > >
                    • Bill Kearney
                      ... The intent of the SRV records is not (directly) to support frequently changing hostname/IP relationships. It s to do what MX records provide for SMTP
                      Message 10 of 12 , Dec 3, 2001
                      • 0 Attachment
                        > > > and SRV's could be maintained with a smaller TTL?
                        > > yeah, I think the TTL is quite small -- two minutes.
                        > >
                        > More generally, the TTL could be linked to presence time, or in more
                        > kerberos like language, ticket duration, right?

                        The intent of the SRV records is not (directly) to support frequently
                        changing hostname/IP relationships. It's to do what MX records
                        provide for SMTP services. That's provide a way to alias a well-
                        known name against a set of other records.

                        For more DNS info see:
                        http://www.dns.net/dnsrd/rr.html
                        http://www.faqs.org/rfcs/rfc2052.html

                        A search on SRV is also insightful. RFCs 3088, 3087, 3105, 2915 and
                        other are of interest.

                        -Bill Kearney
                      • burton@openprivacy.org
                        ... Hash: SHA1 ... I have been running in this config for 3 years. Basically I have run on a dynamic IP with dynamic DNS (yi.org actually), across 3 house,
                        Message 11 of 12 , Dec 4, 2001
                        • 0 Attachment
                          -----BEGIN PGP SIGNED MESSAGE-----
                          Hash: SHA1

                          rahul@... writes:

                          > On a related note,
                          > http://www.purl.org/
                          > maintains a persistent URL framework, used much by the RDF community for
                          > XML namespaces.
                          > What about DNS names?
                          > Services like dyndns already provide such domain services very cheap
                          > or free. The challenge would be to create organizations like purl that
                          > would provide such survices tursworthily and permanently, that is so
                          > that such servers could establish trust relationships
                          > (b.almaden.ibm.com = work.b.nareau.net), and be trusted not to
                          > arbitrarily blink like @home, or if they do, devolve to other servers in
                          > the network.

                          I have been running in this config for 3 years. Basically I have run on a
                          dynamic IP with dynamic DNS (yi.org actually), across 3 house, countless ISPs
                          and countless companies.

                          The really cool thing was my move to LA and back up to SF. Just unplugged my
                          box, plugged into a friends house and it worked. No primary DNS change.

                          In reality the DNS cache update problems are only a slight issue. SMTP can
                          handle this fine but HTTP is of course an issue.

                          > Secondly, every personal hub could have its own DNS to completely eliminate
                          > central naming if desired. So each could have its own local namespace for
                          > resources through the DNS system. Rahul

                          <snip>


                          - --
                          Kevin A. Burton ( burton@..., burton@..., burtonator@... )
                          Location - San Francisco, CA, Cell - 415.595.9965
                          Jabber - burtonator@..., Web - http://relativity.yi.org/

                          Intellectual property does not exist! Get over it!
                          -----BEGIN PGP SIGNATURE-----
                          Version: GnuPG v1.0.6 (GNU/Linux)
                          Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

                          iD8DBQE8DIqIAwM6xb2dfE0RAqYZAKCtFhUmtZVLGA/kpyyH9+Wyp4KzTgCgmN+g
                          Tc1sFtQKLBUG8id27gLuxLI=
                          =Qslb
                          -----END PGP SIGNATURE-----
                        Your message has been successfully submitted and would be delivered to recipients shortly.