OGR27 client 507 / 509

[Wessie]

[16:43] <Wessie> yo
[16:43] <Wessie> hebben we nog een PV v/d DNET projecten?
[16:43] <Wessie> avond overigens
[18:11] <iisschots> weet ik niet
[18:11] <iisschots> volgensmij wilco officieel
[18:11] <iisschots> hoezo?
[19:18] <Wessie> wij van NC zouden graag willen weten waarom client 507 ook OGR27 kan doen
[19:18] <Wessie> en of deze resultaten ook geaccepteerd worden
[19:18] <iisschots> okey
[19:18] <Wessie> omdat DNET zelf aangegeven heeft dat alleen 509 dit kon
[19:19] <iisschots> ik zou zeggen maak er een mooie post van
[19:19] <iisschots> en open een topic
[19:19] <Wessie> waar?
[19:19] <iisschots> /5
[19:20] <iisschots> (wel een TS van meer dan 2-3 regels )

Op zich heb ik al voldaan aan de vragen/eisen van iisschots, maar vooruit.
Wij hebben geconstateerd dat de 507 client van DNET ook OGR27 doet.
We hebben het kunnen vaststellen bij 2 individuele machines.
Zij halen netjes OGR27 op en verwerken deze ook.
Voor zover wij het begrepen hebben is het de bedoeling dat alleen de 509 dit zou kunnen.
Deze bovenstaande clients deden hiervoor het andere OGRNG project de OGR26.

Omdat ik in eerste instatie ook niet geloofd werd (logisch overigens), kom ik natuurlijk ook hier met bewijs.

algemene log van mijn proxy (ophalen):

[16:20] <Wessie> 2009-02-27 15:13:45,Client: 82.**.**.* (client ver: 507) is connecting
[16:20] <Wessie> 2009-02-27 15:13:45,82.**.**.*: assigned ogrng 27/4-7-39-22-44
[16:20] <Wessie> 2009-02-27 15:13:45,82.**.**.*: assigned ogrng 27/4-7-39-23-43
[16:20] <Wessie> 2009-02-27 15:13:45,82.**.**.*: assigned ogrng 27/4-7-39-24-42
[16:20] <Wessie> 2009-02-27 15:13:45,82.**.**.*: assigned ogrng 27/4-7-39-25-41
[16:20] <Wessie> 2009-02-27 15:13:45,82.**.**.*: assigned ogrng 27/4-7-39-26-40
[16:20] <Wessie> 2009-02-27 15:13:45,82.**.**.*: assigned ogrng 27/4-7-39-27-40
[16:20] <Wessie> 2009-02-27 15:13:45,82.**.**.*: assigned ogrng 27/4-7-39-28-38
[16:20] <Wessie> 2009-02-27 15:13:45,82.**.**.*: assigned ogrng 27/4-7-39-29-37
[16:20] <Wessie> 2009-02-27 15:13:45,82.**.**.*: assigned ogrng 27/4-7-39-30-36
[16:20] <Wessie> 2009-02-27 15:13:45,82.**.**.*: assigned ogrng 27/4-7-39-31-35

En een andere client die iets terugstuurd:

[16:23] <Wessie> 2009-02-27 14:47:59,86.**.**.** ,dnet@*.nl,27/4-7-30-52-23,304228795295,1,1,91010507
[16:23] <Wessie> 2009-02-27 14:50:59,v86.**.**.** ,dnet@*.nl,27/4-7-30-49-26,340174711175,1,1,91010507
[16:23] <Wessie> 2009-02-27 14:54:02,86.**.**.** ,dnet@*.nl,27/4-7-30-51-24,331263028073,1,1,91010507
[16:23] <Wessie> 2009-02-27 15:01:37,86.**.**.** ,dnet@*.nl,27/4-7-30-50-25,333781509425,1,1,91010507

Iemand enig idee hoe het nou precies zit.
En natuurlijk wie heeft dit nog meer gezien?

[Bastien]

Ik zou zeggen dat proxyper een bugje bevat. Zie het @ TCF proxy ook dat er af en toe een 508 client werk krijgt terwijl ie anders keurig 507/508 loopt af te schieten.

Maar ik kan ook verzinnen dat de .ini van de client op readonly staat en de client dus de contest niet op gesloten kan zetten... maar dan nog zou de proxy werk ophalen moeten weigeren lijkt mij

Leuk toch

[ Voor 5% gewijzigd door Bastien op 27-02-2009 20:06 ]

[emphasis]

op TCF-proxy zie ik ook al zoiets, maar dan met de 508 client. Geen idee verder over het hoe en wat.

[Wessie]

Ze staan zeker niet op read only, dus dat is het probleem zeker niet.
Het lijkt mij in de 347 proxy te zitten dan?

[Qwerty-273]

uit de changelog (zie meuk: Distributed.net Client 2.9103-509 ):

Version 2.9103-509:
* fix: all: Fix OGR-NG middle mark limit miscalculation on odd rulers

Het betekent dus niet dat versies van voor 2.9103-509 geen OGR-27 kunnen doen - ze leveren alleen geen correcte resultaten af en zullen dus op de keyservers van dnet gewoon dev null in verwezen worden. Zonde van de tijd dus om er aan te werken.
Volgens mij is OGR-NG voorbereid om gewoon gebruikt te worden voor de volgende en volgende OGR (dus na deze kunnen ze gewoon aan de gang met 28).

[Wessie]

Probleem is nu dus wel dat wij koeien op afstand hebben die dit inleveren en waar we niet bij kunnen komen.
Dat is dus wel een groot probleem.
Iemand een oplossing dan?

[Robinski]

Bij mij weten zouden de proxys aan clients ouder dan 509, en proxys ouder dan 347 moeten doorgeven dat OGR gesloten is, wegens die bug.

Daarnaast gooit dnet stubs die door oudere clients gedaan worden inderdaad bij binnenkomst weg, omdat deze zeer waarschijnlijk fout zijn.

Een oplossing heb ik zo 1,2,3 niet... ik zou het eens vragen bij dnet!

[Bastien]

De proxy blijft trouwens maar tegen dezelfde clients <509 en dezelfde proxy's <347 zeggen dat OGR-NG gesloten is. Net alsof ie het niet in de .ini kan zetten... of dat wat daarin komt te staan niet voldoet. Kan aan de proxy/client liggen natuurlijk maar het viel mij zojuist op.

En na nog meer logs door te hebben gespit: de ogr stubs van client 508 op de tcf proxy zijn afgeleverd door verschillende proxy's met versie 347, niet rechtstreeks met een client. Clients worden consequent afgeschoten. Echter als een proxy met versie 347 om de een of andere reden stubs van OGR27 heeft geaccepteerd van een oude client versie dan gaan ze gewoon door. Maar die hoort ze niet meer te krijgen.

Snap er niets van

[Robinski]

Overigens zie ik nog clients OGR-26 stubs inleveren.
Blijkbaar toch een beetje erg te grote buffers gegeven.

[Wessie]

Robinski schreef op zaterdag 28 februari 2009 @ 10:34:
Overigens zie ik nog clients OGR-26 stubs inleveren.
Blijkbaar toch een beetje erg te grote buffers gegeven.

Of teveel uitgestaan natuurlijk.
Maar het is jammer, want het is ook stats vervuiling he

[SandStar]

Wessie schreef op zaterdag 28 februari 2009 @ 11:05:
[...]


Of teveel uitgestaan natuurlijk.
Maar het is jammer, want het is ook stats vervuiling he

Ik filter ze er gewoon uit

[Robinski]

SandStar schreef op zaterdag 28 februari 2009 @ 11:18:
[...]


Ik filter ze er gewoon uit

Heb zelf OGR-26 ook voor een groot deel uit de stats verwijderd.

[Qwerty-273]

Van de mailinglijst over dit probleem:

If you restart the personal proxy frequently, then this will tend to cause this bug to occur when the older clients manage to request OGR-NG work before your proxy has had a chance to talk to the upstream keyservers again.

The next proxy builds will probably fix this problem, but I would recommend that you avoid unnecessarily restarting the personal proxy (or just upgrade your old clients to versions that support OGR-27).