[DNET] Verschillende client troubles

[Mobster]

Ik heb 2 dagen geleden van iemand een lading OGR-24 stubs gekregen. Deze zijn opgehaald met de 477-client van een dnet keyserver. Deze wilde ik in mijn buffer-in importeren. Dit ging helaas niet.

code:

[Jan 29 12:20:14 UTC] Open failed for 'C:\DunMilkaKoei\buff-in.ogr'
                      File is not in distributed.net client format.

Mijn koe is van de lichting 473 en sommige PC's in mijn park (de Athlons) werken zelfs nog met (de snelste) 463-client welke dmv remote buffers hun werk doen.

Als ik mijn Bertha 473 vervang door Bertha 477 werkt het wel. Maar als ik dan mijn oude buff-in.ogr (die ik tijdelijk rename naar buffer) wil importeren krijg ik weer dat probleem dat hij denkt dat het niet in distributed client format is.

Ik ben bang dat als ik de koe op mijn werkstation (van waaruit dus remote gebufferd wordt) upgrade dat mijn remote PC'tjes dan problemen krijgen.

Als ik via via bij OezieWoezie wat stubs ga halen (met een 463 client) dan kan ik ze wel overzetten.

Iemand enig commentaar, tips, bevestiging, ontkenning of whatever hierover?

[Diadem]

Tsja. Wat valt er aan te doen? Weinig vrees ik.

Maar je kunt meerdere clients op je pc-tjes installen. Ze bijten elkaar niet. Dus je gooit ergens in een dir een oude 477 client neer, je eet de stubs op, en zodra die client klaar is, gooi je hem weg en ga je weer met de oude verder.

Je buff-in niet kunnen lezen is ook geen ramp als het OGR-25 stubs zijn. Daar kun je altijd nieuwe van halen bij de server, dus die buff-in's kun je gewoon deleten. Zijn ze niet superenthousiast over bij d.net, maar erg vinden ze het ook niet. (ze verliezen er genoeg door mensen die stoppen etc). Dus als je flusht voordat je overstapt kan je niets gebeuren, behalve een paar honderd KB extra dataverkeer voor het binnenhalen van nieuwe stubs.

[Diadem]

Als eigenlijk 2 mensen aan dezelfde stubs werken (ik copy mijn buff-in, en geef hem aan iemand anders).

Wordt het dan 1x meegeteld maar? Bij RC5 wel, maar bij OGR moeten ze toch alle stubs meerdere keren doen. Dus mag dat?

[Mobster]

Mogen, mogen. Als dat een enkele keer gebeurt zullen ze daar niet moeilijk over doen. Maar het bewust 2x inleveren (of 2x uitrekenen for that matter) van deze stubs is niet de bedoeling.

Doe maar niet dus. Mensen die dat op hele grote schaal gedaan hebben, zijn reeds verwijderd uit de stats.

[[eNeRGy]]

in principe is 2x uitrekenen op verschillende OS'es, CPU's, etc niet slecht, daar draait het project op, maar het is niet de bedoeling als je het zelf doet

[ Voor 5% gewijzigd door [eNeRGy] op 29-01-2003 14:24 ]

[Diadem]

2x inleveren kan natuurlijk niet lijkt mij. Het lijkt mij dat de buff-in zo versleuteld is dat er een ID in zit, zodat 2x dezelfde buff-in flushen geen nut heeft.

Of 2x kraken kan hangt er van af of ze de ID erin sleutelen voor het versturen, of tijdens het verwerken.

Maar het project moet alles 2x (minimaal) doen. Dus wat dat betreft moet 2x uitrekenen geen kwaad kunnen. MAar als't niet mag van d.net mag het nie he.

[Dijkhuis]

ik kan me herinneren dat bij ogr alle stubs in twee runs gedaan werden, en dat dnet kan zien van welke run de stub is. Dus van iedere stub zijn er 2 verschillende, en ieder kan maar 1 keer meegeteld worden.

Maar in de praktijk was er maar weinig controle op het dubbel inzenden van dezelfde stub, waardoor sommige individuen door tig keer dezelfde stub in te zenden heel hoog in de stats kwamen. Die personen moesten dan handmatig door dnet gechecked worden, waarna de dubbele verwijderd werden (en soms ook de persoon zelf).

Inmiddels zou dat verbeterd moeten zijn, maar ik weet niet of dat echt zo is.

[Mobster]

On-topic please

[stappel_]

Diadem schreef op 29 januari 2003 @ 14:32:
2x inleveren kan natuurlijk niet lijkt mij. Het lijkt mij dat de buff-in zo versleuteld is dat er een ID in zit, zodat 2x dezelfde buff-in flushen geen nut heeft.

Of 2x kraken kan hangt er van af of ze de ID erin sleutelen voor het versturen, of tijdens het verwerken.

Maar het project moet alles 2x (minimaal) doen. Dus wat dat betreft moet 2x uitrekenen geen kwaad kunnen. MAar als't niet mag van d.net mag het nie he.

Het ID wordt aan de unit gehangen zodra hij klaar is en in de out file geplaatst wordt. je kan dus de out file op een totaal andere client (met andere ID) versturen en toch krijgt de juiste persoon dan de credits.
Je kan best je buffer copieren naar iemand anders, maar dan moet hij ook een andere ID gebruiken. anders denkt d.net dat je vals speelt door twee keer in te leveren. echter zou ik nooit twee keer dezelfde unit uitrekenen want we weten niet of d.net al met de tweede run is begonnen, het kan dus zijn dat je dan hem voor de tweede en meteen derde keer uitrekend. een beetje zonde dus.

Mobster schreef op 29 January 2003 @ 15:25:
On-topic please

oke paps. vanaf client versie 475 en hoger is er een nieuw buffer formaat gekozen. daar wordt op de site netjes melding van gemaakt. http://n0cgi.distributed.net/faq/cache/273.html . het geldt dus niet alleen voor RC5-72 buffers, maar ook voor OGR. je zult die buffers dus met een oude client moeten uitrekenen. (of stuur maar naar mij)

[Mobster]

Helder en duidelijk antwoord. Thanks stappel_

Heb het voorlopig opgelost door op één PC helemaal los te koppelen van de rest en daar mijn 500 OGR-packets te laten ratelen. Kan ik de rest van de kudde gewoon laten lopen.

Dit betekent dus trouwens ook dat als je met remote buffers werkt (welke loser doet dat nu? ) je met óf 477 óf lager en geen mix moet grazen....