as) United States
`a2) Patent Application Publication (0) Pub. No.: US 2009/0204700 A1
`(43) Pub. Date: Aug. 13, 2009
`
`Satya Sudhakar
`
`US 20090204700A1
`
`(54) COORDINATED PEER-TO-PEER(P2P)
`REPLICATED BACKUP AND VERSIONING
`
`(76)
`
`Inventor:
`
`Gosukonda Naga Venkata Satya
`Sudhakar, Bangalore (IN)
`
`Correspondence Address:
`SCHWEGMAN, LUNDBERG & WOESSNER/
`NOVELL
`PO BOX 2938
`
`MINNEAPOLIS, MN 55402 (US)
`
`(21) Appl. No.:
`
`12/027,843
`
`(22)
`
`Filed:
`
`Feb. 7, 2008
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`(2006.01)
`GO6F 15/173
`(52) US. C0. coeccccccccccccccscssscesssssssssnnnenees 709/224; 709/225
`
`(57)
`
`ABSTRACT
`
`Techniques are presented for peer-to-peer (P2P) replicated
`backup and versioning. Peer clients register and share storage
`with one another for purposes of P2P data replication, data
`versioning, and/or data restoration via a P2P server. The P2P
`server also provides security and management between the
`peer clients. Moreover, the P2P sever can audit behaviors of
`the peer clients and take punitive actions against any of the
`peer clients that violate policy.
`
`«_— 200
`
` RECEIVE A REQUEST FROMA FIRST PEER
`
`210
`CLIENT (FPC) TO CONNECT TO ANOTHER
`
`PEER CLIENT (PC) FOR DATA REPLICATION,
`
`
`DATA VERSIONING, OR DATA
`RESTORATION
`
`
`DETERMINE FOR INCLUSION
`WITHIN THE LIST THOSE
`
`
`AVAILABLESPC’S THAT CAN
`
`
`220
`CURRENTLY RECEIVE AT LEAST
`
` 22]
`SUPPLYING A LIST OF SECOND PEER
`
`ONE MORE CONNECTION FROM
`CLIENTS (SPC’S) HAVING ONE OR MORE
`
`
`
`THE FPC
`SPC’S; THE LIST IS SUPPLIED TO THE FPC
`
`
`
`
`ACQUIRE A SELECTED SPC RECEIVED
`230
`
`FROM THE FPC AND SELECTED FROM
`
`
`THE LIST
`
`C
`
`
`INCREMENTA SERIAL NUMBER
`
`REPRESENTING A TOTAL NUMBEROF
`\ OTHER PC’S CURRENTLY CONNECTED TO
`THE SELECTED PC, AND WHEREIN THE
`SERIAL NUMBERIS INCREMENTED TO
`PRODUCE A PACKET THAT
`REFLECT A CONNECTION TO THE
`INCLUDES THE SERIAL NUMBER
`AND THAT IS SUPPLIED TO THE=[\.
`FPC, AND WHEREIN THE PACKET|541
`INCLUDES A TIME PERIOD FOR
`WHICH THE FPC CAN CONNECT
`TO THE SELECTED SPC AND
`UNIQUE IDENTIFIERS
`IDENTIFYING THE FPC AND THE
`ert nATnN ons
`
`DETERMINE THAT WHEN THE
`SELECTED SPC IS ACQUIRED THAT
`THE SELECTED SPC CANNOT
`ACCEPT A CURRENT CONNECTION
`ANDIN RESPONSE THERETO
`ASKING THE FPC TO WAIT OR HOLD
`UNTIL A PARTICULAR
`CONNECTION IS TERMINATED
`WITH THR SPI RCTFD SPC
`
`242
`
`231
`
`240
`
`SELECTED PC BY THE FPC
`
`250,| SIGN THE SERIAL NUMBER AND SUPPLY THE
`SIGNED SERIAL NUMBER TO THE FPC
`
`DETERMINE THE TIME PERIOD BY CONSIDERING A VARIETY OF FACTORS THAT
`JNCLUDE: HOW MUCH TIME THE SELECTED SPC HAS BEEN BURDENED WITH SHARED
`DATA REQUESTS WITHIN A LAST CONFIGURABLE PERIOD OF TIME, HOW MANY
`CONNECTION REQUESTS WERE MADEOF THE SELECTED SPC IN THE LAST
`CONFIGURABLE PERIOD OF TIME, AND HOW MANYTIMES THE FPC CONNECTED TO THE
`SELECTED SPC IN THE LAST CONFIGURABLEPERIOD OF TIME
`
`
`
`
`
`
`
`
`
` TIME PERIOD FALLS BELOW A THRESHOLD
`
`ENSURE THAT A MINIMUM TIME PERIODIS ASSIGNED TO THE PACKET WHEN THE
`
`
` \
`
`243
`
`Data Co Exhibit 1052
`Data Co Exhibit 1052
`Data Co v. Bright Data
`Data Co v. Bright Data
`
`

`

`Patent Application Publication
`
`Aug. 13, 2009 Sheet 1 of 3
`
`US 2009/0204700 Al
`
`110
`
`121
`
`RECEIVE A REGISTRATION
`PEER CLIENT(FPC)
`DETERMINE FROM THE
`REQUEST FROMA FIRST
`
`
`FIRST PEER CLIENT THE
`
`
`USAGE METRICS
`REPRESENTING ONE OR
`
`
`INTERACTIVELY ACQUIRE
`MORE OF THE FOLLOWING
`
`USAGE METRICS FROM
`
`
`
`
`A TOTALSIZE OF THE
`
`
`
`THE FPC
`120
`FIRST-PEER-CLIENT
`STORAGETO USE FOR THE
`
`
`P2P DATA SHARING AND
`DIVIDE FPC STORAGE ON
`
`
`
`DATA MANAGEMENT,A
`THE FPC INTO A
`
`
`
`CONFIGURABLE
` CALCULATE THE
`REQUESTED NUMBER OF
`
`
`
`THE SECOND PEER CLIENTS
`TOTALSIZE AS A
`NUMBEROF SLOTS(8)IN
`
`
`
`
`THAT THE FIRST PEER
`RESPONSE TO SOME OF
`PRODUCT FOR A FPC
`
`
`
`
`CLIENT WANTSTO USE FOR
`THE USAGE METRICS
`PROVIDED DATASIZE
`
`
`
`
`THE P2P DATA SHARING
`TO SHARE WITH THE
`
`
`
`AND DATA MANAGEMENT,
`SPC’S MULTIPLIED BY
`ALLOCATEA FIRST
`
`
`
`
`A TIME ZONE ASSOCIATED
`THE REQUESTED
`
`NUMBEROFTHE S$’S
`WITH THEFIRST PEER
`
`
`
`NUMBEROF THE SPC’S
`
`
`(FNS) ON THE FPC FOR
`THAT THE FPC WANTS
`CLIENT, AND EXPECTED
`EXCLUSIVE USE OF THE
`
`
`
`
`TIMES DURING A DAY
`TO USE
`FPC
`
`
`THAT THE FIRST PEER
`
`DETERMINE A MAXIMUM
`
`NUMBER OF SECOND
`CALCULATETHE TOTAL
`
`
`SIZE AS A PRODUCT FORA
`PEER CLIENTS (SPC’S)
`RESOLVE THE FNS BY
`
`
`
`
`THAT THE FPC CAN USE
`FPC PROVIDED DATASIZE
`DIVIDING THE8’S BY
`FOR DATA REPLICATION
`
`
`TO SHARE WITH THESPC’S
`
`
`THE REQUESTED
`OR DATA VERSIONING OF
`MULTIPLIED BY A SUM
`
`NUMBEROF THE SPC’S
`
`THE FNS; THE DATA
`ASSOCIATED WITH ADDING
`
`THAT THE FPC WANTS
`
`
`REPLICATION AND DATA
`TO USE
`ONE TO THE REQUESTED
`
`VERSIONING OCCUR VIA
`
`
`NUMBEROF THE SPC’S
`
`
`A P2P COMMUNICATION
`THAT THE FPC WANTS TO
`
`
`BETWEEN THE FPC AND
`FACH OF THE SPs
`
`
`
`100
`
`130
`
`140
`
`150
`
`
`
`
`
`
`
`
`
`
`DETERMINE THE CONFIGURABLE NUMBER
`OF THE SLOTS BY DIVIDING THE TOTAL
`SIZE BY THE SUM, AND WHEREIN EACH
`SLOTIS OF AN EQUAL SIZE WITH
`
`REMAINING ONES OF THE SLOTS
`
`
`
` REGISTER THE FPC, THE S’S,
`AND THE MAXIMUM NUMBER
`
`
`OF SPC’S FOR P2P DATA
`
`
`SHARING AND DATA
`
`
`MANAGEMENT
`
`
`
`
`
`t
`
`MONITOR ACTIONS OF THE FPC IN RELATION TO THE SPC’S ONCE THE FPC BEGINS PARTICIPATING
`IN THE P2P DATA SHARING AND MANAGEMENTWITH THE SPC’S; AND
`DEREGISTER THE FPC WHEN THE ACTIONS VIOLATEA POLICY OR VIOLATE A THRESHOLD
`
`160
`
`170
`
`FIG. 1
`
`

`

`Patent Application Publication
`
`Aug. 13,2009 Sheet 2 of 3
`
`US 2009/0204700 Al
`
`210
`
`220
`
`77]
`
` t
`
` RECEIVE A REQUEST FROMA FIRST PEER
`
`
`<_— 200
`CLIENT (FPC) TO CONNECT TO ANOTHER
`
`PEER CLIENT (PC) FOR DATA REPLICATION,
`DATA VERSIONING, OR DATA
`
`
`DETERMINE FOR INCLUSION
`RESTORATION
`WITHIN THE LIST THOSE
`
`
`AVAILABLE SPC’S THAT CAN
`
`
`CURRENTLY RECEIVE AT LEAST
`SUPPLYING A LIST OF SECOND PEER
`
`
`
`ONE MORE CONNECTION FROM
`CLIENTS (SPC’S) HAVING ONE OR MORE
`
`SPC’S; THE LIST IS SUPPLIED TO THE FPC
`
`
`THR FPPC:
`
`DETERMINE THAT WHEN THE
`SELECTED SPC IS ACQUIRED THAT
`ie THE SELECTED SPC CANNOT
`ACCEPT A CURRENT CONNECTION
`ANDIN RESPONSE THERETO
`ASKING THE FPC TO WAIT OR HOLD
`UNTIL A PARTICULAR
`CONNECTION IS TERMINATED
`WITH THE SPT ROTED SPC
`
`[\,
`AND THATIS SUPPLIED TO THE
`SELECTED PC BY THE FPC
`
`FPC, AND WHEREIN THE PACKET|44
`|
`INCLUDES A TIME PERIOD FOR
`WHICH THE FPC CAN CONNECT
`25OO SIGN THE SERIAL NUMBER AND SUPPLY THE
`TO THE SELECTED SPC AND
`SIGNED SERIAL NUMBERTO THE FPC
`UNIQUE IDENTIFIERS
`IDENTIFYING THE FPC AND THE
`err raren one
`
`DETERMINE THE TIME PERIOD BY CONSIDERING A VARIETY OF FACTORS THAT
`INCLUDE: HOW MUCHTIME THE SELECTED SPC HAS BEEN BURDENED WITH SHARED
`DATA REQUESTS WITHIN A LAST CONFIGURABLE PERIOD OF TIME, HOW MANY
`CONNECTION REQUESTS WERE MADE OF THE SELECTED SPC IN THE LAST
`CONFIGURABLE PERIOD OF TIME, AND HOW MANY TIMES THE FPC CONNECTED TO THE
`SELECTED SPC IN THE LAST CONFIGURABLE PERIOD OF TIME
`
`:
`ENSURE THAT A MINIMUM TIME PERIODIS ASSIGNED TO THE PACKET WHEN THE
`TIME PERIOD FALLS BELOW A THRESHOLD
`
`
`243
`
`FIG. 2
`
` 230
`ACQUIRE A SELECTED SPC RECEIVED
`FROM THE FPC AND SELECTED FROM
`
`THELIST
`
`INCREMENTA SERIAL NUMBER
`REPRESENTING A TOTAL NUMBEROF
`OTHER PC’S CURRENTLY CONNECTED TO
`THE SELECTED PC, AND WHEREIN THE
`SERIAL NUMBERIS INCREMENTED TO
`
`240
`
`231
`
`PRODUCE A PACKET THAT
`
`242
`
`

`

`Patent Application Publication
`
`Aug. 13,2009 Sheet 3 of 3
`
`US 2009/0204700 Al
`
`300
`
`x
`
`301
`
`PEER
`CLIENTS
`
`SERVER
`
`MANAGEMENT
`
`FIG.3
`
`400
`
`401
`
`—
`
`P2P
`MANAGEMENT
`
`SERVER 402
`
`P2P
`\| CLIENT VERSIONING
`SERVICE
`
`FIG. 4
`
`

`

`US 2009/0204700 Al
`
`Aug. 13, 2009
`
`COORDINATED PEER-TO-PEER(P2P)
`REPLICATED BACKUP AND VERSIONING
`
`client, the slots, and the maximum numberof second peer
`clients are registered for P2P data sharing and data manage-
`ment.
`
`BACKGROUND
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a diagram of a methodfor registering and
`[0008]
`configuring a client for coordinated P2P replicated backup
`and version, according to an example embodiment.
`[0009]
`FIG. 2 is a diagram a method for centralized P2P
`data sharing and management, according to an example
`embodiment.
`
`FIG. 3 is a diagram of a P2P data management and
`[0010]
`sharing system, according to an example embodiment.
`[0011]
`FIG. 4isa diagram ofanother P2P data management
`and sharing system, according to an example embodiment.
`
`DETAILED DESCRIPTION
`
`SUMMARY
`
`[0001] Data and information are rapidly becomingthelife
`blood of enterprises. Transactions with customers, opera-
`tional data, financial data, corporate intelligence data; in fact,
`all types of information are now captured, indexed, stored,
`and mined by enterprises in today’s highly competitive and
`world economy.
`[0002]
`Since informationis vital to the enterprise, itis often
`made available twenty-four hours a day, seven days a week,
`and three hundred sixty-five days a year. To achievethis, the
`enterprises have to implement a variety of data replication,
`data backup,and data versioning techniques againsttheir data
`models, users’ storage devices, and/ortheir data warehouses.
`[0003]
`It is not unusual for an enterprise to expend roughly
`$6 for every gigabyte (GB) of data storage used for data
`backup andreplication per year. This is a best case scenario
`[0012] According to an embodiment, the techniques pre-
`and does not include the managementoverhead,risk associ-
`sented herein may be implemented within Novell products
`ated with data loss, restore overheadin the event of data loss,
`distributed by Novell, Inc. of Provo, Utah. Ofcourseit is to be
`periodic tape drive cleansing overhead/cost, higher recover
`understood that any network architecture, device, proxy,
`times when dataislost, etc.
`operating system (OS), or product may be enhancedto utilize
`and deploy the techniques presented herein and below.
`[0004]
`In fact, assuming an enterprise has 10,000 employ-
`[0013]
`FIG. 1is a diagram of a method 100 for registering
`ees each employee having a modest 20 GBofdata, then the
`cost of data backup andreplication is $1,200,000 (20x$6x10,
`and configuring a client for coordinated P2P replicated
`backup and version, according to an example embodiment.
`000). Again, this is best case scenario and does not even
`The method 100 (hereinafter “P2P registration service’) is
`accountfor a variety of overhead costs, which were discussed
`implemented in a machine-accessible and computer-readable
`above. Thus, it can be seen that data backup andreplication
`medium asinstructions that process on a machine (computer,
`for medium tolarge enterprises can easily be in the millions of
`processor-enabled device, etc.) and the P2P registration ser-
`dollars and can affect the enterprise’s bottom line in any year
`vice is accessible over a network. The network maybe wired,
`but most especially during tough or lean years.
`wireless, or a combination of wired and wireless.
`[0005] Additionally, many users of an enterprise never
`[0014] The P2Pregistration service is implemented within
`fully utilize their existing storage capacity. Still, the enter-
`and processes on a P2P centralized server machine. Users
`prise has to retain sufficient backup space to accountfor the
`interact with their client machines (referred to as “peers” or
`situation when a user doesfully utilize his/her storage capac-
`“peer clients” herein) to register with and be configured by the
`ity. So, the reality is and enterprise not only expendsa lot of
`P2P registration service for P2P data sharing and manage-
`time, resources, and money on data backup andreplication
`ment with other peer clients.
`but the enterprise is also wasting and underutilizing a lot of
`existing storage capacity.
`[0015] At 110, the P2P registration service receives a reg-
`istration request fromafirst peer client. Thefirst peer client
`[0006] Thus, itis desirable to have improved techniques for
`desires to share storage associated with its processing envi-
`data backup andreplication within enterprises.
`ronment and desires to have one or more other second peer
`clients remotely located over the network housereplicated
`backup data for the first peer client’s storage or to house
`versioned data for the first peer client’s storage.
`In various embodiments, techniques are provided
`[0007]
`[0016] The request can be received from a user associated
`for coordinated peer-to-peer (P2P) replicated backup andver-
`with the first peer client. Alternatively, the request can be
`sioning. More particularly and in an embodiment, a methodis
`received from an automated service or daemon running ofthe
`provided for registering and configuring a client for coordi-
`first peer client. In some cases, the request can be received
`nated P2P replicated backup and version. A registration
`from an administrator on behalf ofthe first peer client and
`requestis received fromafirst peer client. Usage metrics are
`from a machinethatis not associated withthefirst peer client.
`interactively acquired from the first peer client. The first-
`[0017] Before the first peer client can share storage and
`peer-client storage on the first peer client is divided into a
`have storage accessible via other peer clients, the first peer
`configurable numberofslots in response to someofthe usage
`client has to register via the P2P registration service. The
`metrics. A first numberofthe slots onthefirst peer client are
`registration request received at 110 reflects the initiation of
`allocated for exclusive use of the first peer client. Next, a
`thatregistration.
`maximum number of second peer clients are determined,
`where the secondpeerclients are used bythefirst peer client
`[0018] At 120, the P2P registration service interactively
`for data replication or data versioning of thefirst number of
`acquires usage metrics from the first peer clients. A variety of
`the slots. The data replication and data versioning occur via a
`usage metrics can be received from information obtained
`peer-to-peer (P2P) communication betweenthefirst peer cli-
`from the first peer client. Some of the information may be
`ent and each of the secondpeerclients. Finally, the first peer
`acquired automatically from thefirst peer client, some of the
`
`

`

`US 2009/0204700 Al
`
`Aug. 13, 2009
`
`information may be calculated to produce other information,
`and some information may be acquired from a userthat inter-
`acts on thefirst peer client.
`[0019]
`For example, at 121, the P2P registration service
`determines from the first peer client the usage metrics. The
`usage metrics include one or moreof the following: a total
`size ofthefirst peer client storage to use for P2P data sharing
`and data management; a requested number of second peer
`clients that the first peer client wants to use for the P2P data
`sharing and data management, a time zone associated with the
`first peer client, expected times during a typical day that the
`first peer client is operational, etc. More examples, usage
`metrics that can be acquired from the first peer client is
`provided in detail below with the sample illustration that
`immediately follows the discussion of the FIG. 1 and can be
`used with the process of the P2P registration service.
`[0020]
`In an embodiment, at 122, the P2P registration ser-
`vice calculatesthe total size as a productfora first-peer-client
`provided data size to share with the secondpeerclients mul-
`tiplied by a sum. The sum is acquired by adding one to the
`requested numberof the secondpeer clients that the first peer
`client wants to use for P2P data sharing and data manage-
`ment. For example, supposethe data size thatfirst peer client
`wants to share is 20 megabytes (MB) and the number of
`second peerclients that the first peer client wants to use is 4,
`then the total size 100 MB (20x(4+1)). The extra one permits
`a fifth second peerclient to later come on board and accounts
`for such a situation in advance. Whether one is addedor not
`
`can be a configurable parameter or profile that is set by an
`administrator. More discussionofthis is presented in greater
`detail below withthe illustrations that immediately follow the
`discussion of the FIG. 1.
`
`In some cases, at 123, the P2P registration service
`[0021]
`determines the configurable numberofthe slots by dividing
`the total size by the sum. Eachslot is of equal size with the
`remaining ones of the slots. So, in our previously presented
`example each slot is 100 MBdivided by 5 (numberfor second
`peer clients+1 (accounting fora later extra second peerclient
`that wants to participate)), which equals 20 MB’s.
`[0022]
`In some cases, the administrator may decide that
`reserving an extra slot of the storage from the first peer client
`is not desired. In such a case, at 124, the P2P registration
`service calculatesthe total size as a productforthe first-peer-
`client data size to share multiplied by the requested number of
`the second peerclients that the first peer client wants to use.
`[0023] At 130, the P2P registration service dividesthefirst
`peer client storage on thefirst peer client into a configurable
`numberof slots in response to someofthe usage metrics, as
`discussed above with the processing associated with 122-124.
`Thefirst peer client retains one or more ofthe slots and the
`other slots on the first peer client are available for use by
`second peer clients during P2P data sharing and data man-
`agement.
`[0024] At 140, the P2Pregistration service allocatesa first
`numberof the configurable numberofslots on the first peer
`client for exclusive use of the first peer client. So, at 141, the
`P2Pregistration service resolves the first numberofslots by
`dividing the configurable numberof slots by the requested
`numberof the second peer clients that the first peer client
`wants to use.
`
`[0025] At 150, the P2P registration service determines a
`maximum numberof second peer clients that the first peer
`client can use for data replication and/or data versioning of
`the first numberof slots (allocated to the first peer clientat
`
`140). The data replication and data versioning occur via P2P
`communications betweenthefirst peer client and each of the
`second peerclients.
`[0026] At160, the P2P registration service registers thefirst
`peer client, the configurable numberof slots, and the maxi-
`mum numberof secondpeer clients for P2P data sharing and
`data management, whichis associated with P2P data replica-
`tion and data versioning.
`[0027] According to an embodiment, at 170, the P2P reg-
`istration service monitors actions of the first peer client in
`relation to the second peer clients once the first peer client
`beginsparticipating in the P2P data sharing and data manage-
`ment with the second peer clients. The P2P registration ser-
`vice can deregister the first peer client whenthe first peer
`client takes any action that violates one or more policies or
`that violate one or more configured thresholds (discussions of
`scenarios for these situations are presented in greater detail
`herein and below).
`[0028]
`Some example illustrations and variations on the
`processing associated with the P2P registration service are
`now presented for purposes of comprehension.
`
`How Much Storage to Share:
`
`[0029] Each user who wants to have data replicated has to
`share a little more than an equal amountofhis/her disk space.
`So, say that a user wants 20 GBto bereplicated across 4
`locations. Then the user has to share 100 GB. An administra-
`
`tor can configure to share only 80 GBalso but sharing more
`gives certain advantages, such as what was mentioned above
`with respect to the processing at 122. Again, whether 80 or
`100 MBis used dependonthe setting chosen by the admin-
`istrator of the P2P registration service.
`[0030] The P2P registration service coordinates the P2P
`connections.
`
`A Peer Client User Interface (UI):
`
`[0031] Whenthe peerclient USis first installed it asks for
`the time zone and whattimes of the day and how muchtime
`(estimated) the peer client is on-line. This was discussed
`above with references to the usage metrics at 120-121. This is
`used to select appropriate peers for the user of the first peer
`client, so that the on-line times overlap with the user associ-
`ated with the first peer client. Next, the peer client UI is used
`to ask for how manyreplicas/versioning clients that the user
`wants to have. A minimum can beset to 4 and maximum can
`
`be configurable up to 10. But ifthe user chooses more than 4
`then there are many peers, which may connect tofirst peer
`client. However, the P2P registration service coordinatesthis
`so that at max ‘x’ (x is also configurable) secondpeerclients
`may connectto thefirst peer client. This coordination can also
`be achieved using cryptographically, which is explained in
`greater detail below. The USis also used to ask as to how
`manyparallel connectionsthe user can accept when servicing
`data of other peers with a minimum set to 1. The number
`chosen is again displayed under a text box (of the UI) fora
`second option that says how many connections the user can
`make to other peer’s in requesting and servicing the user’s
`data. This second option is read-only and displays the same
`numberasthe user has chosen withfirst option. So, ifthe user
`allows servicing 2 peer’s data simultaneously then the user in
`turn is serviced by 2 peers at most for the user’s data. These
`connections are associated with the P2P data sharing and
`managementandit is noted that connection to the P2P regis-
`
`

`

`US 2009/0204700 Al
`
`Aug. 13, 2009
`
`tration service is always available to the first peer client and
`the secondpeerclients of the network. Moreover,all of these
`settings can be changedat any time via the UI or administra-
`tive override.
`
`Number of Replicas or Versioning Second Peer Clients
`
`In an embodiment, the user chooses 4 or more rep-
`[0032]
`licas that are incremented by one (# of replicas+1) for storage
`allocation. This is because if 4 users come on-line and share
`between themselves then what happensto a 5th user who has
`newly joined? Such a user will not have any oneto store data
`with. One wayto solve this is to always have somefree space.
`(This also solves the problem where the user did not come
`on-line for a very long time, say, for months/years in which
`case the user canretrieve the data but the whole system has
`still got the space.) Now,if the free spaceis there for 5th user,
`that user can share at least 2 of the remaining 4 and when 6th
`and 7th user joins he can share the remaining with them.
`Allocation is done such a waythat there will beat least 4 slots
`left between different users. Thefirst to come has the most of
`
`the redundant data. Consider the following example scenario
`where T standsfora particular time frame and X standsfor a
`particular user:
`[0033]
`TO: XO joined andoffers 5 slots. XO gets 2 slots.
`[0034] T1: X1 joined and offers 5 slots. XO gets one more
`slot and X1 gets 2 slots
`[0035]
`12: X2 joined andoffers 5 slots. XO gets one more
`slot (so, XO got all his 4 slots) and X1 gets one moreslot and
`X2 gets 2 slots.
`[0036]
`13: X3 joined and offers 5 slots. X1 gets one more
`slot (So, X1 got all his 4 slots) and X2 gets one moreslot and
`X3 gets 2 slots.
`
`Free Space Management by the P2P Registration Service
`
`wayrelated to A or not. If not then it does not issue a packet
`for access. The P2P registration service then sees how many
`other peer clients are currently connected to A, according to
`usage data associated with A and how many morepeerclients
`can permissibly connect to A according to A’s setting of max
`concurrent connections set by A’s owner/administrator. Two
`example cases are now presented:
`
`Case 1:
`
`Ifno peer clients are connectedto A orif at least one
`[0039]
`more connection is possible to A then the P2P registration
`service gives B, an access packet signed by the P2P registra-
`tion service that contains a serial number, which gets incre-
`mented for each connection to A; a time period (T); and the
`names(unique identifiers) associated with both A and B. The
`time period (T) is determined by taking the following into
`consideration:
`
`1.How muchAis burdenedon average in thelast ‘x’
`[0040]
`hours ofuptime ofA. This can be configured with a default of
`15 hours, for example.
`[0041]
`2. How manyconnection requests camefor A in the
`last ‘x’ hours of uptime ofA.
`[0042]
`3. How many times B connected to A in thelast ‘x’
`hours of uptime of A.
`[0043] But, a minimum timeperiod is guaranteed to ensure
`any useful talk or transfer happens within that time. The P2P
`registration service marks that much time period+somegrace
`period (say 3 minutes) for B andnotesthat B is now engaged.
`[0044] Now, B on receipt of this packet from the P2P reg-
`istration service sends the packet to A after connecting. A
`verifies the signature, sees the time period, and allows B to
`continue to talk if the serial numberis greater than last con-
`nection’s serial numberor if the serial numberis not used and
`is at most less than 10 than last connection’s serial number.
`
`This configured limit of 10 is so that B can keep track of at
`[0037] The space offered is divided into chunks and is
`most the last 10 numbers as to whether they are used ornot.
`managedby the P2Pregistration service. Theslot is allocated,
`Again, this number 10 is configurable. Now, at the end ofthat
`in some embodiments, by best fit algorithm. The space
`time period, B can choose to continue talking with A if there
`offered by a user is at the most divided intoxslots. This x can
`are no more requesting connections to A.
`be 6 by default. Note that this is a maximum.In actualprac-
`tice, the entire space may be used as a single chunk;if the
`space is being offered by the first peer client is small in size.
`Optionally, there can be a minimum limit on the spacethatis
`offered by thefirst peer client. This max numberx is to avoid
`too many chunks; there by avoiding connecting too many
`peers to a single system if the user offers more space. How-
`ever, if the user has huge memory requirements with no
`compatible systems available with similar storage then
`optionally the user can select to have more than max number
`of connecting peers and accept the overhead. Otherwise, the
`user can havesingle replica ofhis data and have otherreplicas
`after suitable storage is available by waiting until then.
`
`Case 2:
`
`[0045] There is an existing connection from some other
`peer client to A and no more connections to A are possible
`according to the P2P registration service’s usage data for A.
`Now,B is asked to wait. If there are manyclients like B that
`are also waiting to connect with A, then a preference algo-
`rithm can be used. The preference is based on P.; where
`P=(numberofhours requests are serviced by a particular peer
`client in its last x hours of up time/4)/(numberof hours the
`services of peers used by the particular peer client in the last
`x hours of up time).
`[0046] After service is over, B reports the following to the
`P2P registration service:
`the processing throughput
`it
`received from A,the time period it was allowed to connectto
`A, how muchdata it downloaded from A and uploaded to A.
`The sameinformation is reported by A to central server. These
`2 reports must substantially match with one another. If not
`then there is an attack by either A or B (discussed below).
`Now,the P2P registration service decides how many connec-
`tions A should have at most based onthis data.If all peers are
`experiencing low service then the P2P registration service
`reduces the numberof concurrent connections possible for A
`also limiting A’s numberof concurrent requests for its peers
`
`Server Coordinated Connections
`
`Onepeer client (B) that wants to connect to another
`[0038]
`peer client (A); B asks the P2P registration service for per-
`mission. Actually, B can ask the server for a list of peers for
`whom B’s data is replicated and B can subsequent ask the P2P
`registration service to give permission to connectto oneofthe
`peers depending on the on-line availability ofthose peers. For
`the remaining discussion A and B are used for purposes of
`illustration and comprehension although itis to be understood
`that there can many peers, such as 10 or even more (config-
`ured amount). The P2P registration service sees if B is any-
`
`

`

`US 2009/0204700 Al
`
`Aug. 13, 2009
`
`along with max spacethat A can haveoroffer. If B reports low
`throughput and if peer’s requesting their data on B also
`reports low throughput then the problem is with B and B has
`to increase its bandwidth or resources so the P2P registration
`service reduces connections for B and limits maximum rep-
`licas that B can have and max space B can offer until through-
`put is increased. If the space that A/B can hold is reduced by
`the P2P registration service thenthe extra peers’ data already
`existing on A/Bis replicated to other free space of other nodes
`by its peers on notification from the P2P registration service.
`The P2Pregistration service in this case gives access to that
`other nodes’ free space to these peers.
`[0047] The minimum bandwidth is guaranteed by the P2P
`registration service using past or historical usage data.
`
`From A’s Point of View:
`
`[0048] Assume the max numberof connections to service
`peers is set to 1 on A. When a connection comes from B, if
`there is already a connection from C then even if the max
`connections setting is 1 still A allow the connection from B
`and verify the packet presented, which B received from the
`P2Pregistration service. If the packetis valid then A services
`B and shutdownsthe service with C after C’s time period is
`over. C’s time period may overlap with B’s time period as
`there is a grace time in the entire system that can be config-
`ured in by the P2P registration service. Or, A is continuing
`connection with C.
`
`In Case of Internet—if Inside Firewall
`
`peers holding B’s data to deletethat data andfree the space up.
`The P2P registration service also redirects all peers whose
`data is residing on B to replicate to other peer clients’ free
`space by giving the access to those peerclients’ free space.
`
`Free Rider Attack Scenario #2
`
`[0052] Peer client B can selectively close the servicing of
`other peers or B does not allow connections to B when it
`should; this can be addressed in two ways. Either B can
`deny/close just a particular peer client’s service or B can
`close/deny a connection of a randomlyselected peer. In the
`first case, the particular peer is asked by the P2P registration
`service to relocate the particular peer’s data to other free space
`of other peer clients by giving access to that particular peer
`client along with marking B for further watching and moni-
`toring. Now,B is asked to free space ofthis particular peer and
`a new peeris assigned for that space. If such cases become
`more frequent, say B’s actions continue and reachesa thresh-
`old of ‘x’ number, then B is notified about this and is marked
`as attacker. If B still does not change its behavior then B is
`removedfrom the P2P data sharing and data management.If
`B randomly denies/closes connections then each time this
`event happens, the peers notify the P2P registration service
`about B’s actions and the P2P registration service keep track
`of these events and when a certain threshold is reached, the
`P2P registration service notifies B and removes B, when B
`does not change the behavior.
`
`Evil Attack Scenario #1
`
`[0049] The network discussed herein for which the P2P
`data management and data sharing is associated applies
`‘B’ can wrongly notify the P2P registration service
`[0053]
`equally to the Internet as well as an enterprise’s internal
`Intranet. One difference is with a firewall environment. The
`about A saying that A is not servicing B’s requests or B can
`report low processing throughput or low access time when B
`technique discussed whena peerclient is inside firewallis
`already technically within a P2P world andis called “push
`attempts to access A. In such case, the P2P registration service
`request”. The client wanting to downloada file sends a so
`checks the corresponding data reported byB. If the reporting
`called “push request”to a server (a push proxy, which can be
`information from B does not match whatotherpeerclients are
`different from the P2P registration service) for the other
`reporting about A, then either B is denigrating A or B is just
`remote client whichis inside firewall, to initiate the connec-
`mistaken about A. So, the P2Pregistration service marks both
`tion instead (to “push”the file). The proxy sends a “push
`A andBfor further monitoring with respect to this event and
`request”to that other remote client on behalfofthe client. The
`assigns a new peer to B and another new peer to A and then
`remoteclient then sendsthefile to the push proxy from which
`removes the A-B P2Passociation. If B again repeats this trick
`the first client gets it.
`with its new peer, then the P2P registration service marks B
`[0050] Various attack scenarios can also be detected by the
`again for further monitoring and again changesthe peerrela-
`P2P registration service. Some of these are discussed in the
`tionship with B andits new peer and then gives B yet another
`illustrative examples below and some are also presented
`peer. If this continues for a threshold or policy vio