Boinc MegaFlush Controller

[smeaggie]

Boinc MegaFlush Controller
wat is dit? De Boinc MegaFlush Controller is een applicatie die het mogelijk maakt om op eenvoudige wijze workunits te sparen en te bewaren voor een MegaFlush.
waarom? Het is gebleken dat het soms moeilijk is om workunits efficient te sparen door verschillende omstandigheden. Het is mogelijk om een aantal workunits te downloaden en daarna de netwerkverbinding van BOINC uit te schakelen tot aan de MegaFlush. Hiermee krijg je echter ook geen nieuwe workunits meer binnen en haal je niet een echte MegaScore, omdat je maar een beperkt aantal workunits kan gebruiken. Er zijn methoden voor om meer te sparen, maar deze zijn dermate arbeidsintensief dat het niet efficient is voor de mensen die met complete netwerken crunchen. Hier gaat verandering in komen met de Boinc MegaFlush Controller.
hoe werkt dit dan? Het programma gedraagd zich als proxy-server. Het staat tussen Boinc en de project server in. Het programma analyzeert de datastromen tussen beide en kan dus zien welke workunits naar de clients gaan en ziet wat er weer terug gestuurd wordt naar de project servers. Er is een web interface aan verbonden waarmee deze gegevens bekeken kunnen worden, en belangrijker: het is mogelijk om een MegaFlush vast te zetten. Vervolgens kan de proxy-server vaststellen of een workunit (result) die geupload wordt in aanmerking komt voor een MegaFlush en deze achterhouden in een cache op de computer waar de proxy draait. Workunits die niet in aanmerking komen voor de MegaFlush (bijvoorbeeld door een te korte deadline) worden gewoon geflusht naar de project server. Dit heeft ook gevolg dat de Boinc client gewoon nieuwe workunits kan downloaden van de servers. Het enige wat op de clients moet gebeuren is een HTTP proxy instellen.
werkt dit voor alle projecten op Boinc? Het is de bedoeling meerdere projecten te ondersteunen, ik draai echter alleen SETI@Home. In eerste instantie wil ik dus het sparen voor een MegaFlush implementeren voor SETI@Home, maar als ik het protocol goed bekijk moet het niet moeilijk zijn om dit ook te implementeren voor andere projecten.
wat zijn de nadelen? Een van de nadelen is dat ik momenteel (in de alpha versie dus) alleen werk met SETI@Home. Het is nu niet mogelijk voor een ander project te crunchen als je deze proxy gebruikt, aangezien de results van het andere project naar SETI gestuurd zullen worden. Misschien is deze zware beperking nog aanwezig in de eerste beta! Ten tweede is het zo dat bij uploaden van een result Boinc er niet bij verteld wat de deadline van de result was. De deadlines moeten dus geregistreerd worden bij het downloaden, wat gevolg heeft dat dit dus ook door de proxy moet. Je kan dus niet 100 workunits downloaden buiten de proxy om, en daarna laten flushen door de proxy. Ten derde kan het zijn dat de project servers de achtergehouden workunits als "Lost In Action" beschouwen, omdat zowel Boinc als de project server niet weten waar de workunit gebleven is. Dit komt omdat Boinc altijd een complete lijst workunits die bij Boinc bekend zijn naar de server stuurt en de op de proxy achtergehouden units staan hier dus niet bij. Dit is uiteraard op te lossen maar ook daar komen kleine addertjes onder het gras meegluren...
kan je al voordelen bedenken? makkelijk in te stellen, zowel clients als de proxy server instellingen zijn eenmalig, na de MegaFlush gedraagt het programma zich als "normale" proxy meerdere clients kunnen flushen door één proxy server
waar kan ik het downloaden? Nog nergens. Het programma verkeert nog niet eens in beta status en is dus nog niet verkrijgbaar. Momenteel staat het dataverkeer te verzamelen voor een uitgebreide protocol analyze, die al aardig gevorderd is.
kan ik beta tester worden? Ik heb al aanmeldingen ontvangen voor beta testers. Deze waren er wel erg vroeg bij, tegen de tijd dat ik beta's ga verspreiden zal ik dit melden in dit topic. Ik kan er wel bij vertellen dat het in eerste instantie dus zal gaan om mensen die alleen SETI draaien op hun Boinc client.
waar is dit topic voor? Ik wil natuurlijk graag reacties peilen op dit initiatief. Maar vooral om jullie op de hoogte te houden van de vorderingen. Je kan hier al je vragen stellen over het project, ook suggesties zijn zeer welkom. Houdt u er rekening mee dat ik dit niet voor mijn werk maak, het is een hobby project! Dagelijkse updates kan ik niet garanderen...

[Gijsh]

Ziet er goed uit!!
Ik draai zelf geen BOINC, maar dit zou best een reden kunnen zijn het wel te doen!

[Crack]

Is het ook mogelijk met deze tool om een off-line PC te laten rekenen?

[Kristof]

mooi initiatief
uiteraard hoop ik dat je het ook voor andere projecten voor elkaar krijgt

[smeaggie]

Crack schreef op vrijdag 17 november 2006 @ 18:53:
Is het ook mogelijk met deze tool om een off-line PC te laten rekenen?

helaas niet. de proxy gaat nu uit van directe (live) verbinding met de Boinc client en de project server. Waarschijnlijk kan ik aan de hand van mijn huidige onderzoek wel zo'n tool schrijven, het is een kwestie van het protocol kennen natuurlijk... Ik zal het idee onthouden

[smeaggie]

Kristof schreef op vrijdag 17 november 2006 @ 18:59:
mooi initiatief
uiteraard hoop ik dat je het ook voor andere projecten voor elkaar krijgt

als het project slaagt met SETI@Home wil ik wel een poll starten voor het volgende project. Ik verwacht niet al te grote verschillen in protocollen die gebruikt worden, en de data is allemaal in XML dus het moet makkelijk te parsen zijn. Ik hou bij de bouw in ieder geval rekening met ondersteuning voor meerdere projecten!

[Wom]

Crack schreef op vrijdag 17 november 2006 @ 18:53:
Is het ook mogelijk met deze tool om een off-line PC te laten rekenen?

Dit zou een uitkomst voor mij zijn. Mocht je een volgend project zoeken zou voor mij persoonlijk deze hoog op je agenda mogen staan

[APClll]

Ik zie dat je over belangstelling niet te klagen hebt
Het zou mooi zijn als je het werkend krijgt.

Hopelijk krijg je het af voor DSSF

[Black Piet]

Smeaggie is oke ole ole!!!

Zeer goed initiatief [maar dat wist je natuurlijk al]. Wat me nog niet geheel duidelijk is of mijn reguliere internetverkeer ook over deze "proxy" gaat als ik deze voor SETI installeer.

Ach, ik ga het wel merken.... Hopelijk gaat het nog lukken voor de flush voor mijn baas

[smeaggie]

APClll schreef op vrijdag 17 november 2006 @ 19:22:
Ik zie dat je over belangstelling niet te klagen hebt
Het zou mooi zijn als je het werkend krijgt.

Hopelijk krijg je het af voor DSSF

eigenlijk ben ik al te laat voor de DSSF, aangezien we al workunits binnen krijgen die we pas na 4 december hoeven in te leveren... deze zijn moeilijk vast te houden als je nog meer binnen wilt krijgen

@iedereen: ik zal na dit project eens kijken of ik ook een offline-connector in elkaar kan draaien...

@Black Piet: deze proxy draait standaard op port 16002, wat je gewoon in Boinc kan instellen. Je overige programma's kunnen geen gebruik maken van deze proxy.

[ Voor 12% gewijzigd door smeaggie op 17-11-2006 19:26 ]

[smeaggie]

update

er doen zich wat verschillen voor tussen windows en linux lijkt het, of het zijn de versie verschillen in boinc, hoewel de data die boinc verstuurt er precies hetzelfde uitziet op linux en windows reageert berkeley totaal niet op de windows versie
ik ben met een rewrite van start gegaan zodat ik wat meer opties kan ondersteunen en later ook betere support kan maken voor andere projecten.

nieuw bedachte optie: de proxy moet verbinding kunnen maken via een "reguliere" proxy

[Kristof]

Een idee, maar je weet nooit:
Enige tijd geleden heeft Sloompie ook aan het programmeren egweest voor een monitorng tool voor BOINC. De tool heeft wel andere functies dan de jouwe. Maar misschien kan die wel wat meer info geven ivm de gebruikte protocollen etc.

zie Sloompie in "\[BOINC/Rosetta] Monitoring-tool : BAM"

[smeaggie]

Kristof schreef op dinsdag 21 november 2006 @ 10:04:
Een idee, maar je weet nooit:
Enige tijd geleden heeft Sloompie ook aan het programmeren egweest voor een monitorng tool voor BOINC. De tool heeft wel andere functies dan de jouwe. Maar misschien kan die wel wat meer info geven ivm de gebruikte protocollen etc.

zie Sloompie in "\[BOINC/Rosetta] Monitoring-tool : BAM"

als ik het goed lees heeft Sloompie een boinc manager geschreven, die dus een remote control kan doen voor boinc instellingen / stats e.d. Hierin zit dus geen communicatie tussen boinc <-> project server, deze protocollen is Sloompie denk ik niet tegengekomen. De proxy is fundamenteel anders aangezien deze het netwerk verkeer onderschept tussen boinc en de project server, en juist geen commando's hoeft te sturen naar boinc...

[Anoniem: 159695]

We horen het wel wanneer we kunnen gaan beta-testen.
Misschien dat het nog lukt voor de eindejaars flush _{hint, hint}

Of er moeten nog meer mensen die normaliter geen SETI draaien ook willen testen

[ Voor 25% gewijzigd door Anoniem: 159695 op 21-11-2006 12:56 ]

[smeaggie]

voor die laatste groep mensen heb ik goed nieuws: het is mogelijk ik heb de basis een complete rewrite gegeven, waardoor het wel erg simpel wordt om andere projecten te ondersteunen. per server waar boinc contact mee zoekt kan je een java klasse aangeven die gebruikt moet worden voor de communicatie. deze java klasse moet voldoen aan een uber-simpele interface en werkt met makkelijke HttpRequest en HttpResponse objecten, dus eventuele java programmeurs zullen straks zelf aan de slag kunnen met andere projecten. de koppeling tussen project server en communicatie klasse wordt gedefinieerd in een properties file dus makkelijker kan het niet hierover komt later nog wel een 'developers-manual'...

[TheZoo]

smeaggie schreef op vrijdag 17 november 2006 @ 19:06:
[...]

helaas niet. de proxy gaat nu uit van directe (live) verbinding met de Boinc client en de project server. Waarschijnlijk kan ik aan de hand van mijn huidige onderzoek wel zo'n tool schrijven, het is een kwestie van het protocol kennen natuurlijk... Ik zal het idee onthouden

Ik hoop dat je dat gaat lukken, scheelt nogal wat rekenkracht voor mij.

[smeaggie]

TheZoo schreef op dinsdag 21 november 2006 @ 14:03:
[...]

Ik hoop dat je dat gaat lukken, scheelt nogal wat rekenkracht voor mij.

ik heb er al wel even over nagedacht. het kan vrij eenvoudig door een utility te schrijven die aan de ene kant een boinc client faked (richting de berkeley servers) en aan de andere kant een berkeley server faked (richting je boinc client). hiertussenin moet ie dan alle data vasthouden... moet te doen zijn, maar dit komt na de proxy

[Pavla]

Klinkt erg goed, als dit lukt hebben de Dutch Power Cows weer een eenzienlijk voordeel in datgene waarin wij het beste zijn: Megaflushen Ik neem aan dat je het protocol met ethereal onderzoekt?
In ieder geval veel succes!

[smeaggie]

Pavla schreef op dinsdag 21 november 2006 @ 19:21:
Klinkt erg goed, als dit lukt hebben de Dutch Power Cows weer een eenzienlijk voordeel in datgene waarin wij het beste zijn: Megaflushen Ik neem aan dat je het protocol met ethereal onderzoekt?
In ieder geval veel succes!

ethereal? wazzda? neuh, ik ben vrij simpel bezig geweest, ik moest het verkeer toch van het ene socket naar het andere overgooien, dus heb er een System.out.print(byte) tussen gezet

toch even gekeken op de website van ethereal, ziet er mooi uit, maar zo geavanceerd heb ik hier niet voor nodig.

kleine update

de contents in de requests en responses worden in de bijbehorende HttpRequest en HttpResponse objecten naar een XML DOM tree geparsed om aanpassingen makkelijk te realiseren. Het geheel begint vorm te krijgen. Uit deze XML DOM tree haal ik voor SETI@Home nu bijvoorbeeld al deadlines van workunits die gedownload worden

[sus]

YEAH! _dit_ zijn de berichten die ik graag zie. Wij als DPC zijn natuurlijk beroemd en berucht vanwege onze MegaFlushes, en ik ben hier zelf ook in het geheel niet vies van.

Ik hoor het wel als ik kan betatesten

Al zou ik wel graag zien dat de tool geschikt is voor Rosetta ipv Seti *hint*

[ Voor 15% gewijzigd door sus op 22-11-2006 10:49 ]

[Black Piet]

SuspiciouS schreef op woensdag 22 november 2006 @ 10:48:
Al zou ik wel graag zien dat de tool geschikt is voor Rosetta ipv Seti *hint*

SETI HEEFT VOORRANG! Maar dat moge duidelijk zijn!
Gelukkig is Smeaggie een Grazzie en SETI lid, dus de kans dat Rosetta dit als eerste krijg is natuurlijk nihil

[sus]

maar zou er zoveel verschil in protocollen zitten tussen rosetta en seti ? Lijkt mij van niet, aangezien de client hetzelfde blijft

[Diabolical]

smeaggie schreef op woensdag 22 november 2006 @ 10:20:
[...]

ethereal? wazzda? neuh, ik ben vrij simpel bezig geweest, ik moest het verkeer toch van het ene socket naar het andere overgooien, dus heb er een System.out.print(byte) tussen gezet

toch even gekeken op de website van ethereal, ziet er mooi uit, maar zo geavanceerd heb ik hier niet voor nodig.

Ethereal is mooooooooi. Gebruik hem om op het netwerk wat te snoopen....

Ennieweej, als je je proxy proxy aware maakt zorg er dan voor dat ie ook met authenticating proxies overweg kan, kan ik hem ook gebruiken...

* Diabolical is toch trots op medeteamlid

[smeaggie]

seti@home is nummer 1, maar volgens mij is rosetta ook veel gedraaid, dus rosetta zet ik op nr. 2! waarschijnlijk geen probleem: boinc communiceert de data volledig in XML, en deze wordt al geparst naar een XML DOM tree dus moeilijk kan het niet zijn (als de basis maar werkt )
het zou zelfs kunnen zijn dat je voor andere boinc projecten al gelijk werkt, omdat de xml nodes toch hetzelfde heten ("result" en "work_unit" e.d.)... een ideaal beeld

authenticating proxies, zover ben ik nog niet, maar het was wel de bedoeling... overigens wat ik nog niet helemaal duidelijk gemaakt heb: ik schrijf alleen ondersteuning voor HTTP proxies

[Diabolical]

smeaggie schreef op woensdag 22 november 2006 @ 15:10:
authenticating proxies, zover ben ik nog niet, maar het was wel de bedoeling... overigens wat ik nog niet helemaal duidelijk gemaakt heb: ik schrijf alleen ondersteuning voor HTTP proxies

NP.....

Zolang ie maar kan authenticaten....

[DigiK-oz]

smeaggie schreef op dinsdag 21 november 2006 @ 10:24:
[...]
als ik het goed lees heeft Sloompie een boinc manager geschreven, die dus een remote control kan doen voor boinc instellingen / stats e.d. Hierin zit dus geen communicatie tussen boinc <-> project server, deze protocollen is Sloompie denk ik niet tegengekomen. De proxy is fundamenteel anders aangezien deze het netwerk verkeer onderschept tussen boinc en de project server, en juist geen commando's hoeft te sturen naar boinc...

Klopt helemaal. Echter, ik heb ook met het idee rondgelopen om een proxy-achtig iets te maken voor BOINC, en dus ook het protocol tussen de servers en de BOINC client geanalyseerd. Door andere prioriteiten heb ik dit niet verder uitgewerkt. Maar ik ben zeer geintresseerd in je project, en als ik op enige manier kan helpen dan hoor ik het graag.

Succes in ieder geval!

[smeaggie]

@Sloompie: alle hulp is welkom! vooral met betrekking tot communicatie met andere projecten. Voorlopig echter moet ik nog e.e.a. oplossen in de basis, want op dit moment werkt het nog niet lekker. Als de basis communicatie vlot verloopt (dus als een "normale" (caching) proxy) ga ik echt dieper in op de protocollen, hoe de xml precies in elkaar zit. Hier weet jij misschien al meer van af dan ik, naar welke projecten heb jij gekeken? ik heb tot nu toe alleen seti gezien

[learn_more]

ik weet niet of het werkt voor seti, maar bij "leiden classical" kan je op internet zien wanneer een deadline verloopt (je moet ingelogd zijn).
kan je dan niet de html rippen en die deadlines gebruiken?
screenshot van deadlines:

[MAX3400]

Helemaal goed dit want ik zie namelijk nog steeds geen enkele reden waarom ik vandaag alvast WU's uitreken met een deadline van kerst ofzo. Dan spaar ik liever op bepaalde manieren en flush ik de ene dag 2 WU's en de volgende keer 80 ofzo.

[smeaggie]

TheGambler schreef op maandag 04 december 2006 @ 01:13:
ik weet niet of het werkt voor seti, maar bij "leiden classical" kan je op internet zien wanneer een deadline verloopt (je moet ingelogd zijn).
kan je dan niet de html rippen en die deadlines gebruiken?
screenshot van deadlines:
[afbeelding]

de deadlines zijn ook uit de download info te halen, dus als je een work unit download via de proxy registreert deze dat al. Dit onthoudt ie gewoon en vergelijkt hij tijdens het uploaden van een result. voordeel: er hoeft niet ingelogd te worden op een project website, dus geen username/password etc, waardoor het weer makkelijker is de proxy met meerdere mensen te gebruiken ook geen last van veranderende html pagina's, en hoef geen parser schrijven

[learn_more]

smeaggie schreef op maandag 04 december 2006 @ 13:28:
[...]
de deadlines zijn ook uit de download info te halen, dus als je een work unit download via de proxy registreert deze dat al. Dit onthoudt ie gewoon en vergelijkt hij tijdens het uploaden van een result. voordeel: er hoeft niet ingelogd te worden op een project website, dus geen username/password etc, waardoor het weer makkelijker is de proxy met meerdere mensen te gebruiken ook geen last van veranderende html pagina's, en hoef geen parser schrijven

da's waar, maar naderhand als de proxy later is ingesteld zou dit een optie zijn

[smeaggie]

TheGambler schreef op maandag 04 december 2006 @ 17:38:
[...]


da's waar, maar naderhand als de proxy later is ingesteld zou dit een optie zijn

tsja dat zou een optie kunnen zijn het is natuurlijk mogelijk om via een scheduler update aan de benodigde info te komen welke work units bezig zijn en daar vervolgens een deadline van te halen uit de html pagina... niet geheel onmogelijk, ik zet hem op de NiceToHave lijst

[smeaggie]

update

---

belangrijk probleem: de java sockets waren te traag om mee te werken (lees: 1KB/s) waardoor boinc last kreeg van timeouts met downloaden/uploaden van workunits en results (aangezien dit gecached wordt door de proxy en dus niet gelijk doorkomt). Dit probleem is waarschijnlijk verholpen, de fout zit in de JVM. sun beweert dat het een "feature" is, meerdere java developers beweren dat het een bug is... ik hou me buiten de discussie en gebruik nu de work-around die verder toch geen invloed heeft op de werking van de proxy

en: ik ben bezig met de webbased GUI te maken. Is het bezwaarlijk om een kleurenschema aan te houden dat verdacht veel geinspireerd is door tweakers?

[ Voor 12% gewijzigd door smeaggie op 06-12-2006 16:09 ]

[smeaggie]

de gui: een homebrew webservertje wordt automatisch gestart vanwaar de hele proxy te sturen is, misschien gaat ie nog wel stats bijhouden ook

het kleuren schema lijkt me duidelijk

[Anoniem: 167389]

wat is dit meer als wat BOiNCview doet...dacht dat je hiermee ook het netwerk aan/uit kon zetten?

[ Voor 42% gewijzigd door Anoniem: 167389 op 07-12-2006 00:01 ]

[smeaggie]

Anoniem: 167389 schreef op woensdag 06 december 2006 @ 23:59:
wat is dit meer als wat BOiNCview doet?

het kan automatisch results sparen van meerdere clients tegelijkertijd voor een MegaFlush... stel dat je het netwerk uitzet in boinc, maar voor de flushdatum ben je door je WU's heen? met de proxy kan je gewoon nieuwe downloaden, de results die je upload worden door de proxy achtergehouden tot aan de MF datum (mits de deadline van de WU dit toestaat natuurlijk)

[ Voor 41% gewijzigd door smeaggie op 07-12-2006 00:06 ]

[Anoniem: 167389]

Zolang als het maar naar de machine gaat die er om vraagt. Als een andere machine het verwerkt weet de BOiNC server index van niets en gaat opspelen. Is dit al in praktijk getest..... accepteerd de server het werk dat terug komt van de proxy? Als je bijv de 'contact every x days op bijv ver over de deadline zet', zou er genoeg werk in de task buffer moeten komen. Dan een simpele connect/disconnect script op de client om op de flushdag alles los te laten. Bij WCG zou dat maximaal 7x24 uur zijn. Nadien wordt een extra kopie verzonden, hetgeen niet in dank afgenomen wordt door niet megaflushers in een quorum omgeving..... er is een klein beetje respijt voor late returns, maar de extra kopie in een quorum is niet meer te stoppen. Normaal staat die BOiNC buffer op default 0.1 dag. Wat ik me ook afvraag is of de servers weten hoeveel werk er open staat en of ze maar blijven sturen zonder result returns. WCG heeft een daglimiet van 120... komt het niet terug, gaat de limiet om laag.

Wil de lol niet onderdrukken, maar als werk gedaan wordt en de server zegt uiteindelijk 'nee' heb je een megadowner.

[smeaggie]

de server accepteerd het werk dat door de proxy geflusht wordt, absoluut zeker, ik heb al granted credit voor diverse tests die ik gedaan heb, van verschillende PC's op mijn netwerk hier. Ik zie het probleem (nog) niet. Waarschijnlijk wil de project server inderdaad geen workunits kwijt raken, maar ook daar heb ik nog wat trucjes voor... er is meer ongein uit te halen dan je denkt

[Megaflix]

Smeaggie, als er een wu richting zijn deadline kruipt, neemt hij dan wel genoeg tijd om het nog te versturen, of verstuurt hij pas óp de deadline?

[smeaggie]

Megaflix schreef op donderdag 07 december 2006 @ 11:59:
Smeaggie, als er een wu richting zijn deadline kruipt, neemt hij dan wel genoeg tijd om het nog te versturen, of verstuurt hij pas óp de deadline?

als een client een result naar de project server stuurt die buiten de megaflush valt vanwege te korte deadline stuurt de proxy hem gelijk door naar de project server. het heeft toch geen nut om die ook achter te houden. Er worden dus alleen results in een cache geplaatst als deze daadwerkelijk in aanmerking komen voor een megaflush

ik zeg wel leuk "hij doet dit en dat" maar tot nu toe wordt er nog helemaal niks in een cache geplaatst... huidige status: registreren wat gedownload wordt en wanneer het weer geupload moet worden.

[smeaggie]

tijd voor een update, het is alweer veel te lang stil... hoe komt dat? vrij simpel: ik ben gaan bughunten omdat het niet super liep met windows/linux verschillen. Aangezien 1 van de targets toch wel platform onafhankelijkheid is, ben ik een tijdje bezig geweest om de boel op te lappen. Het werkt nu een stuk beter Ook heb ik een stukje veiligheid ingebouwd met betrekking tot data management. Alle data wordt nu periodiek weggeschreven naar de hard disk, om data verlies te voorkomen. Complete lijst aanpassingen:

• data management is beter geregeld (periodiek opslaan, veiliger)
• first run vraagt op de console naar eerste instellingen (tcp ports etc.)
• mogelijkheid om de servers te binden aan een specifieke netwerk interface
• shutdown-hook die ingrijpt als de JVM aflsuit om nog laatste data op te slaan
• http server implementatie verbeterd (subdir en plaatjes support )
• monitoring thread die alle services in de gaten houdt en zonodig restart. *)
• bij wijzigingen in instellingen worden indien nodig automatisch services herstart. *)

*) services: http server, proxy server, datamanagement service.

[MAX3400]

Goed werk smeaggie; gaat een en ander nog draaibaar zijn binnen 10 dagen? Want dat is toch een mooie week voor oud&nieuw...

[smeaggie]

nah binnen 10 dagen zal wel niet lukken, ga maar ouderwets sparen
ik wil niet het risico lopen dat we een complete DPC MegaFlush aan credits verliezen omdat mn software nog in alpha versie loopt

[ Voor 49% gewijzigd door smeaggie op 13-12-2006 10:32 ]

[smeaggie]

tsja, de nachtelijke bughunt sessies duren lang, maar ik leer zelfs nog wat bijvoorbeeld dat proxies soms met de HTTP headers mogen moeten klooien, en omdat ik dat (nog) niet deed boinc wat raar reageerde op sommige communicatie... nu ook dat verholpen is, weer lekker verder gegaan met de dynamische opbouw van het geheel de data manager kan nu dynamisch project managers inladen die vervolgens serverhandlers registreren en data van 1 bepaald project bijhouden. De data manager zorgt vervolgens dat alle project managers netjes om de paar seconden opgeslagen worden op de harde schijf. ook even in praktijk getest of de shutdown-safety thread ingrijpt als de JVM gesloten wordt... het werkt

rest nu nog de XML data analyzeren, mogelijkheid maken om flushes te definieren en results in een cache te plaatsen misschien vóór 2007 dus nog een beta!

[Megaflix]

iedere keer als ik deze post geupdate zie denk ik dat ik de beta kan downloaden

[smeaggie]

nah, ik hou jullie graag af en toe op de hoogte voordat er gedacht wordt dat ik er niks meer aan doe he ik hoop voor het einde van het jaar toch wel een beta te hebben

[Black Piet]

smeaggie schreef op vrijdag 15 december 2006 @ 00:27:[it-bable

Ik moet eerlijk zeggen dat ik geen flauw idee heb wat je nu zegt, maar globaal lees ik dat je vooruitgang hebt geboekt.

Ben vandaag heerlijk vrij, dus kan Tweakers een beetje vol gaan spammen.

[Diabolical]

Black Piet schreef op vrijdag 15 december 2006 @ 09:12:
[...]


Ik moet eerlijk zeggen dat ik geen flauw idee heb wat je nu zegt, maar globaal lees ik dat je vooruitgang hebt geboekt.

Ben vandaag heerlijk vrij, dus kan Tweakers een beetje vol gaan spammen.

Post de stats dan ff

[Black Piet]

Ik ben er al mee aan de slag...

[smeaggie]

tijd voor wat frustratie boinc communiceert in XML met de project server... dacht ik het is zo'n geweldig brakke XML dat geen enkele java XML parser er ook maar iets van kan bakken het is gewoon misvormd van begin tot eind, dus moet het even anders geimplementeerd worden... zoals altijd: elk nadeel heb ze voordeel, het geheel wordt er wel wat sneller door omdat er nu geen XML documenten meer geparst hoeven (wat dus meestal fout bleek te gaan maar wel tijd kostte).

[Pavla]

smeaggie schreef op donderdag 21 december 2006 @ 16:35:
tijd voor wat frustratie boinc communiceert in XML met de project server... dacht ik het is zo'n geweldig brakke XML dat geen enkele java XML parser er ook maar iets van kan bakken het is gewoon misvormd van begin tot eind, dus moet het even anders geimplementeerd worden... zoals altijd: elk nadeel heb ze voordeel, het geheel wordt er wel wat sneller door omdat er nu geen XML documenten meer geparst hoeven (wat dus meestal fout bleek te gaan maar wel tijd kostte).

Even een hart onder de riem steken dan maar, gewoon stug doorgaan en GoT helemaal volspammen met vragen over JAVA. Dan gaat het op den duur helemaal goedkomen. Succes!

[smeaggie]

lol dank je hier is helaas niks aan te doen: xml tags die niet altijd gesloten worden, attributen zonder quotes, meerdere rootnodes, het lijkt nergens op ik heb het maar anders gedaan, eigenlijk simpeler en sneller, rauwe contentdata door een buffered stringreader gooien en scannen sta alweer te testen, morgen resultaat

[smeaggie]

en wederom een update, met goed en met slecht nieuws

edit:
het goede nieuws: cachen werkt!
het slechte nieuws: bug ontdekt in boinc die het mogelijk maakt om te cheaten, details verwijderd...

[ Voor 74% gewijzigd door smeaggie op 22-12-2006 21:11 ]

[MAX3400]

Weer geen beta...

Volgende post van smeaggie moet een beta bevatten hoor...

[Megaflix]

smeaggie schreef op vrijdag 22 december 2006 @ 16:15:
Ook ik heb deze details uit mijn quote gehaald

Dat is wel een échte bug dan en eentje die prioriteit 1 heeft om te fixen, want credits krijgen zonder results te uploaden kan gezien worden als cheaten.

[ Voor 14% gewijzigd door Megaflix op 22-12-2006 21:42 . Reden: zie post boven ]

[Diabolical]

Megaflix schreef op vrijdag 22 december 2006 @ 16:45:
[...]

Dat is wel een échte bug dan en eentje die prioriteit 1 heeft om te fixen, want credits krijgen zonder results te uploaden kan gezien worden als cheaten.

Is ook cheaten.. pas dus op... je moet ook zien te voorkomen dat anderen dit kunnen reproduceren.

[ Voor 9% gewijzigd door Diabolical op 22-12-2006 18:40 ]

[smeaggie]

zo, even de details hiervan verwijderd, het is natuurlijk niet de bedoeling dat dit ooit gebruikt wordt! ik moet dus de reports nog even fixen met de uploads, want cheaten is NIET de bedoeling van de proxy!

verder ziet het er wel goed uit, het idee werkt dus wel

edit: voorlopige bugfix: de reports worden ook netjes in de cache geplaatst... boinc & berkeley hoeven niet meer te klagen

[ Voor 18% gewijzigd door smeaggie op 22-12-2006 21:22 ]

[woolysheep]

Is er al meer informatie over dit programma bekend? Status wat betreft het ondersteunen van verschillende projecten etc?

[smeaggie]

de status: de programmeur had (heeft) nog even wat prive beslommeringen waar ik jullie niet mee zal vermoeien het blijkt nog niet te werken met meerdere result reports in 1 scheduler request, dus daar moet aan gesleuteld worden... Daarna issie toch echt bijna in beta, mijn vrije tijd neemt wat toe in de avonduren dus er is hoop voor de ouwejaarsflush 2008 .

[Adm.Spock]

smeaggie schreef op vrijdag 22 december 2006 @ 21:13:
zo, even de details hiervan verwijderd, het is natuurlijk niet de bedoeling dat dit ooit gebruikt wordt! ik moet dus de reports nog even fixen met de uploads, want cheaten is NIET de bedoeling van de proxy!

verder ziet het er wel goed uit, het idee werkt dus wel

edit: voorlopige bugfix: de reports worden ook netjes in de cache geplaatst... boinc & berkeley hoeven niet meer te klagen

Meld dit dan wel aan de dev'jes bij BOINC.... die willen dit graag weten om het gat te dichten

[learn_more]

smeaggie schreef op maandag 15 januari 2007 @ 11:02:
de status: de programmeur had (heeft) nog even wat prive beslommeringen waar ik jullie niet mee zal vermoeien het blijkt nog niet te werken met meerdere result reports in 1 scheduler request, dus daar moet aan gesleuteld worden... Daarna issie toch echt bijna in beta, mijn vrije tijd neemt wat toe in de avonduren dus er is hoop voor de ouwejaarsflush 2008 .

mocht je nog betatesters nodig hebben voor de volgende projecten:
leiden classical, UD-grid

ik dev zelf ook, dus ik kan miss wat zinnige feedback geven

[sus]

ik wil rosetta

[Anoniem: 167389]

.... en toen?

[Pim.]

Had je een kick aan een topic gegeven zonder er een behoorlijke post van te maken