Vlákno názorů k článku Boinc: distribuované výpočty doma od Frn - ".. kontrolní mechanismy, které jsou implementovány na straně...

  • Článek je starý, nové názory již nelze přidávat.
  • 26. 5. 2006 11:49

    Frn (neregistrovaný)
    ".. kontrolní mechanismy, které jsou implementovány na straně serveru a sledují, zda některý účastník nepodvání a neposílá falešná data .."

    Víte o tom nědo nějaké podrobnosti ?
    Už z principu je nemožné, aby server věděl, jaké vysledky má klient vrátit. Těžko tedy může seriozně konrolovat správnost jeho výsledků.

    Takže zbývají jenom dvě rozumné možnosti :

    a) stejná data se posílají více klientům a jejich správnost se potrdí tím, že všichni náhodně vybraní klienti vrátí stejné výsledky. Jenže tímto způsobem bude výrazně klesat propustnost výpočetní sítě.

    b) server mezi "neznámá" data přimíchá i "svůj" kousek dat, který vygeneroval sám a ke kterým zná výsledek. Musí to samozřejmě dělat tak, aby se podvržený kousek nedal detekovat.
    Správnost výsledku z celého balíku se pak dá ověřit tím, že výsledek ze "známé" části má "známou" hodnotu.

    c) uplně jinak. Jak ??
  • 26. 5. 2006 12:09

    Hon_za (neregistrovaný)
    Ano, na vetsine BOINC projektu se pouziva metoda (a). Kazda Work Unit je duplikovana podle toho, jak je nastaveno Quorum a rozeslana jako ResultID masinam a vracene vysledky se porovnavaji. Tim se take kontroluje reliabilita mezi jendotlivyma platformama, osetruje se necitelne overclockovani a dalsi problemy, ktere by mohli nepriznive ovlivnit vysledky.

    (b) se v podstate take pouziva, protoze kazdy resultsID je prirazen dane masine, ma misto v databazi serveru, file_signature atp.

    (c) je treba "znat" format vystupu, co treba v pripade Climatu neni zrovna primitivni jako u SETI.
    Server neprijme data od neregistrovane masiny, resp. registrovaneho usera. Krome HostID se pouziva i posloupnost RPC volani, takze to take neni snadne osidit.

    Tech moznosti je hodne a pouzivaji se ruzne kombinovane a rozhodne to neni tak derave jako SETI zombie (classic), kde lidi podvadeli, znehodnocovali vysledky, zatezovali servery a vubec moc neprinaseli vysledky na x let stare a vedecky prestarle aplikaci.
  • 26. 5. 2006 19:45

    dotcom (neregistrovaný)
    treba tak ze tusi priblizne co ma vyjit a pokud se to co klient posle hodne lisi od ocekavaneho tak to necha prepocitat i nekomu jinymu?
  • 26. 5. 2006 20:39

    Hon_za (neregistrovaný)
    Koncept validizace se pouziva u naproste vetisny projektu. Proste se srovnaji 3-4 vysledky stejn work unit, a pokud se nejaky signifikantne lisi, oznaci se za invalid.
    Aktualne a se zvysenou poroznosti se to resilo jak na SETI Beta pri prechodu na Enhanced verzi (nova aplikace a novy zpusob analyzy sumu), tak treba na Einsteinu pri kompilacich optimalizovanych aplikaci.