With scheduler restrictions in place, client loses information about the participant's team and resource share.

[Ageless]

For the past couple of weeks Pirates@Home tested scheduler restrictions, where only 6.1.14 clients (and later also above) would get work. All below it would get a message that their client wasn't high enough and an immediate 24 hour deferral.

The problem is that when this goes on long enough, the client will lose information like what team the participant is on and what resource share is used. I've tested it with 5.10.45 and it only gave my name and the last amount of credits/RAC that it knew of. I am not on a team according to my BOINC and my resource share is showing as 100 where it should be 850.

According to Eric Myers: "If the scheduler rejects the connection based on version number then there is no RPC exchange, and the client looses track of what team you are in."

[Nicolas]

Ideally, there should be different ways to say "You're in no team" and "server isn't sending the team information in this reply".

[Ageless]

The problem is that since there is a version restriction in place, you're not getting through the scheduler, so your data isn't updated from the database. You're pointed directly to the door, whether you were on a team or not.

[Nicolas]

Exactly: if you don't "get through the scheduler", it should say "I have no idea what team you're in", not "you're in no team"; so that the client keeps its old data.

No idea if this is possible without breaking protocol compatibility though.

[Ageless]

Server versions used on Pirates: both 5.10.45 and 6.1.14
Client versions it was on, exactly the same numbers.

And although I pointed at the scheduler as the culprit, it may well be the client that's at fault here as that's the one losing the information. So what files all say what team I am in, besides client.state_xml? Both the sched_*.xml files as well? Do they update client_state.xml?

[Contact]

This is a duplicate of ticket:417

[Ageless]

Replying to Contact: Thank you, Contact. I was looking for that ticket, but couldn't find it. OK, closing this one, going over to ticket:417

[davea]

(In [15232]) - scheduler: there were several situations where the scheduler

would send a reply without having looked up the user and team in the DB; e.g.:

• client version# is too low
• DB is down
• host is blacklisted It would then send a full scheduler reply, including a blank team name and other missing info.

Fix this by setting reply.nucleus_only initially (this causes a minimal reply to be sent) and clearing it only if the host/user/team lookup succeeds. Fixes #417, #633 (I think)