| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
| World Community Grid Forums
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 24
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Groan . . .
UD chose a very simple path by always creating a new registration (device) and never merging devices. This created a desire in some people to merge devices. BOINC is trying to accommodate these people (the customer is always right) but it is turning into an infinite number of special cases. This is a common situation that programmers run into again and again. Things that look simple become very complex in practice. Perhaps there is an elegant algorithm that can merge devices with simplicity, but we have not yet discovered it. Oh well! Lawrence |
||
|
|
Jord
Advanced Cruncher Joined: Dec 30, 2005 Post Count: 148 Status: Offline Project Badges:
|
Cross Project ID
----------------------------------------Each host generates an internal cross-project ID, which is the MD5 of the concatenation of its domain name, IP address, free disk space, and a timestamp. This is reported to the projects to which the host is attached. The projects convert it to an external cross-project ID by hashing it with the owner's email address (this is intended to prevent spoofing). The external ID is exported in statistics files. Whenever a scheduler reply indicates that it has generated a new host record (e.g. because a bad RPC seqno suggests that this is a duplicate host) the client generates a new internal host CPID. Host ID We haven't found a universal hardware-level mechanism (CPU chip ID, MAC address) for uniquely identifying computers. So we do it in software as follows: When a computer first contacts a project's scheduling server, the server creates a database record for the computer , which includes a host ID and an RPC sequence number. The computer ID and the RPC sequence number are also stored in the client's client_state.xml file. The client increments the RPC sequence number on each scheduler request. If the scheduling server receives an RPC with a sequence number less than the expected sequence number (usually indicating that the user has copied the client_state.xml file between computers) it creates a new database record and returns a new ID.
Tears in my eyes
How they fall like rain to the floor |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
BOINC is trying to accommodate these people (the customer is always right) but it is turning into an infinite number of special cases. What's the special case? Surely a machine with no hardware changes whatsoever that is restored from a 2-day old backup should be treated as the same machine it was when the backup was made? |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Still not true. If you don't want to learn the details, that's fine.
If anyone else is interested to know, please ask. I don't mind explaining the process for anyone interested in the technical details. In short: the CPID is irrelevant here. The host_cpid is regenerated by the client when the host_id changes. Neither id is the CPID. Yes, it's complicated! So: host_cpid - generated by the client from domain name, IP address, free disk space, and a timestamp. host_id - assigned by the server, and uniquely identifies the device. CPID - a whole other topic. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
CPID - a whole other topic. Okay. Then someone should re-write some of the code. In this instance, I mean the log output. How are we supposed to discuss things when variables are being reported ambiguously in logs? The log reports "New host venue:" -- it seems adequate to call this "venue". The log reports "Generated new host CPID" -- yet it's not adequate to refer to this as CPID because of some other CPID somewhere else. So, for clarity, when I refer to CPID, I'm referring to the one that the log reports as such. (ie. host_cpid in the client_state file) [Edit 1 times, last edit by Former Member at Apr 16, 2008 12:11:33 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
BOINC are looking for volunteers.
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
If the scheduling server receives an RPC with a sequence number less than the expected sequence number (usually indicating that the user has copied the client_state.xml file between computers) it creates a new database record and returns a new ID. That same page goes on to describe WCG's host matching to prevent duplicate records for the same machine. It doesn't appear to be working. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
As I said (twice) this doesn't apply in your case. It only applies to clean installations.
|
||
|
|
Jord
Advanced Cruncher Joined: Dec 30, 2005 Post Count: 148 Status: Offline Project Badges:
|
That same page goes on to describe WCG's host matching to prevent duplicate records for the same machine. It doesn't appear to be working. You have had a couple of scheduler requests between your backup and now. You yourself admitted that it was old work it was trying to upload/report, which happens through the scheduler. At that moment the scheduler log on the server had a sequence number that was higher than the one in your backup. So as soon as you hooked up your backup and started BOINC, it contacted the server sending along the sequence number from the backup. The scheduler found that the two numbers didn't match and you got a new hostID with a new sequence number that will increase again at each scheduler contact.
Tears in my eyes
----------------------------------------How they fall like rain to the floor [Edit 1 times, last edit by Ageless at Apr 16, 2008 12:55:58 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
That same page goes on to describe WCG's host matching to prevent duplicate records for the same machine. It doesn't appear to be working. You have had a couple of scheduler requests between your backup and now. You yourself admitted that it was old work it was trying to upload/report, which happens through the scheduler. At that moment the scheduler log on the server had a sequence number that was higher than the one in your backup. So as soon as you hooked up your backup and started BOINC, it contacted the server sending along the sequence number from the backup. The scheduler found that the two numbers didn't match and you got a new hostID with a new sequence number that will increase again at each scheduler contact. It is also worth mentioning in that it is normally not possible to merge the host records when the sequence numbers get out of order. This prevents the same host record from being used for 2 computers when the BOINC directory is copied over to install BOINC on a new host. |
||
|
|
|