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

uServ project

Expand Messages
  • bert@akamail.com
    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
    Message 1 of 12 , Nov 30, 2001
    • 0 Attachment
      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.
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 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.
                  • 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 9 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 10 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 11 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 12 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.