| 7 | | So we do it in software as follows: |
| 8 | | When a computer first contacts a project's scheduling server, |
| 9 | | the server creates a database record for the computer , |
| 10 | | which includes a host ID and an RPC sequence number. |
| 11 | | The computer ID and the RPC sequence number are also stored in the client's `client_state.xml` file. |
| 12 | | The client increments the RPC sequence number on each scheduler request. |
| | 5 | So we use two software mechanisms. |
| 20 | | This mechanism can lead to situations where a project's server has multiple database records for a single computer. |
| 21 | | For example, this will occur if the user deletes the `client_state.xml` file. |
| 22 | | The user can merge these duplicates into a single record via a web interface. |
| | 14 | BOINC has mechanisms to |
| | 15 | * Prevent two computers from having the same ID when a volunteer |
| | 16 | clones their BOINC data directory; |
| | 17 | * Avoid creating duplicate host records when a host loses its ID |
| | 18 | (e.g. because its client state file is deleted). |
| | 19 | * Allow users to merge duplicate host records. |
| 30 | | * To merge a single computer, open its Summary page, and click on "Merge this computer". You will see a list of computers eligible to be merged with this one, and you can select any or all of them. |
| 31 | | * The "Your computers" page has a link '''Merge computers by name'''. This feature lets you automatically merge all eligible computers having the same domain name. This is handy if you run a "computer farm" and periodically reformat all the drives. |
| | 26 | Leaderboard sites show statistics from multiple BOINC projects, |
| | 27 | and may want to show credit for hosts |
| | 28 | summed across all the projects in which they participate. |
| 33 | | == Alternate identification method at World Community Grid == |
| 34 | | |
| 35 | | In absence of a merge feature at this project, WCG introduced an alternate method called ''host matching'' to recognise previously existing devices to prevent new / duplicate registrations. For that the server compares standard information exchanged during server-client communications being: |
| 36 | | |
| 37 | | * user name |
| 38 | | * domain_name |
| 39 | | * ip_addr (the ip of the client on the local network) |
| 40 | | * operating system name |
| 41 | | * processor vendor |
| 42 | | * memory |
| 43 | | |
| 44 | | The most recent record that matches this criteria (if found) will be re-used. It will cancel any results currently assigned to the client, and then issue new work. This is because a user might be trying to clear out some work that was causing some form of trouble. If any of this information is hidden through for instance setting the <suppress_net_info> flag in the cc_config.xml file suppressing the IP address or domain_name, the method fails and will create a new device registration. |
| | 30 | Each host generates an '''internal cross-project ID''', |
| | 31 | which is the MD5 of the concatenation of its |
| | 32 | domain name, IP address, free disk space, and a timestamp. |
| | 33 | This is reported to the projects that to which the host is attached. |
| | 34 | The projects convert it to an '''external cross-project ID''' |
| | 35 | by hashing it with the owner's email address |
| | 36 | (this is intended to prevent spoofing). |
| | 37 | The external ID is exported in statistics files. |
