Nytt Playground

Hva må gjøres

  • Finne krav til systemet / Lage en kravspesifikasjon
  • Implementere / utvide eksisterende løsninger

Funksjonalitet

Her kan dere komme med ønsker om funksjonalitet ved det nye systemet.

  • Alt som kan gjøres i det gamle systemet :)
  • Individuelle brukere som knyttes opp mot lag.
  • Individuelle oppgaver knyttes opp konkurranser.
  • Støtte C# programmeringsspråket
  • Støtte flere språk: haskell, lua, scheme, prolog, etc.
  • Kompileringsfeilmeldinger.
  • Bruker-autentisering opp mot admin/organizer/judge/contestant for hver enkelt konkurranse.
  • Støtte flere kjøre-noder?
  • Støtte standard oppgave-formater / validatorer etc. (hvis det finnes en standard)
  • Støtte strukturert input/output for oppgavene
  • Submit's boer defineres som nettop dette, og du boer kunne se historien over dine submits (med status), alle submits i konkurransen, og kanskje alle submits totalt.
  • Ren og klar separasjon mellom front-end og back-end.
  • Burde det vaert stoette forskjellige «skins» for forskjellige «instanser» (generell Playground, IDI Open 2010, etc)?
  • Et bruker-program maa ikke kunne skrive til disk, accessere netverk, etc. Det siste er i dag gjort med IP-tables regler.
  • Fasit-svar maa aldri sendes til kjoere-noder.
  • Aa stoette nye spraak burde vaere like enkelt som «apt-get install brainfuck» og redigere litt paa et kjoerescript.
  • Fett hvis systemet skalerer til «internasjonale» konkurranser.

Spoersmaal

  • Skal det vaere baade Linux og Windows noder, skal vi bruke Mono paa Linux, eller skal alt kjoeres paa Windows? Det foerste gjoer at man kan submit'e baade Visual Studio C++ og GCC C++.
    • Jeg synes vi primært burde støtte programmeringsspråk, ikke kompilatorimplementasjoner, dvs ingen proprietære extensions. Så langt det er mulig synes jeg alt burde kjøre på samme maskinvare og plattform, siden det ikke er bra om et program kjører mye bedre på en node enn en annen. — Tor Gunnar Houeland 2009/05/11 10:37
      • Jeg er veldig enig i prinsippet. Tenkte kanskje dette kunne gjoere ting lettere for de stakkarene som sitter med Visual Studio? — Nils Grimsmo 2009/05/11 14:34
        • Problemet her er hvis koden ikke kompilerer og man ikke får noe tilbakemelding om hvorfor. Hvis tilbakemelding for kompileringsfeil inneholder feilen istedenfor bare «noe gikk galt» tror jeg ikke det vil være noe problem lenger. — Tor Gunnar Houeland 2009/05/11 16:42
    • MONO til å kjøre C# er vell ikke helt top. Men kjipt å ha Windows kjørenoder også da. Hvordan står det til med C/C++ og for den saks skyld andre språk på f.eks. CYGWIN/MINGW? Noen som vet? Kjørenodene bør i grunnen være så like som mulig og «spise fra samme kø» for at ingen skal ha fordeler av å bruke ulike språk. — Ola Natvig 2009/05/11 16:13
      • Hvis det trengs flere typer noder kan det være mulig å dele dem opp basert på språk? Det er fremdeles uheldig, men i hvert fall bedre om environmentet varierer basert på språkvalg enn basert på (u)flaks da du trykket submit. Men er det faktisk nødvendig? — Tor Gunnar Houeland 2009/05/11 16:44
      • Hvis vi kan kjøre C/C++/Fortran/Lisp/Scheme/Python/Ruby/Perl+++ under CYGWIN på windows så klarer vi oss med kun Windows noder. Jeg tror ikke det er noen mulighet å kjøre C# under MONO, hvis noen skal programmere C# under IDI Open så sitter de i Visual Studio, jeg tror ikke MONO er helt kompatibelt (Wikipedia sier at MONO er på .NET version 2.0 med de fleste 3.0 funksjoene, M$ er på versjon 3.5 og det er en del nye ting). Alternativet er jo å droppe C# støtte. Men det er heller ikke bra. Ola Natvig 2009/05/11 19:25
  • Skal det vaere som i dag, at wed-siden «venter» til ditt program har blitt kjoert foer (kanskje nice for brukeren), eller skal web-siden «laste ferdig» med en gang. Du maa da eventuelt sjekke en status-side for resultat.
    • Hvis noen har lyst til å jobbe med websiden, synes jeg det ville være fint om brukeren kan fortsette å bruke websiden mens ting kjører, og at resultater og andre meldinger kommer opp automatisk i et fancy grensesnitt når de er klare. Men det er en del jobb og slikt som ikke skjer hvis ingen brenner for det :) — Tor Gunnar Houeland 2009/05/11 10:58

Problemer med naavaerende loesning

  • Hver instans (Playground, IDI Open 2007, …) er helt separat. Ny back-end ble bare sjekket ut fra CVS hver gang vi skulle gjoere noe nytt.
  • Det submit'es en fil, og du faar timing fra naar du trykker paa kjoer (kjipt i konkuransens siste sekund…)
  • Det brukes SQLite, som kanskje ikke skalerer?

Forslag til implementasjon

  • En sentral MySQL-DB
  • Vi har en tabell som inneholder liste over språk, med felter for kommandolinje for kompilering, samt kjøring
  • Submissions får en oppføring i en tabell (eks: «Submissions»)
  • Når en bruker trykker «Run», legges den aktuelle submissionen i en kjørekø (som er en annen tabell i den samme DB-en)
  • Når en node er ledig, sjekker den regelmessig kjørekøen
  • Finnes det en jobb, kompileres den og kjøres
  • Output sjekkes mot «fasit», og en oppføring blir lagt i en «Results»-tabell

Fordeler med denne implementasjonen:

  • Vi utnytter flere noder (ytelsen vil øke lineært med antall noder, i teorien :P)
  • En sentral mysql-DB gjør det lettere å administrere enn en SQLite+MySQL-DB
  • Lett å legge til nye språk: Bare legg til en rad i tabellen som lister opp språk
  • Hvilket språk vi velger å applikasjonen som kjører submissions i vil ikke begrense valget av hva vi koder webgrensesnittet i

Hvis noen ser noen problemer med dette, før det opp. :)

  • Å skifte til en meget distribuert løsning bør sjekkes godt i god tid før den faktisk skal brukes til noe, under realistisk mengde og type last =) Noen uheldige typer database-krøll kan være katastrofale.
  • Hvordan sikrer man at bare en kjørenode får fatt på «submission»? (har MySQL tilstrekkelig med isolasjonsnivåer osv.)
    • Jeg sjekket, og ser ut til at MySQL støtter å låse en tabell eksplisitt. - Hallgeir
    • Kjørenodene kan spørre hoved-noden om å få en «oppgave», så er det ikke mysql som trenger å håndtere det.
      • ja, men før eller siden må du ha noe fancy-schmancy-synkroniserings-skit.
  • Hva med vanlig batch system. qrsh funker fett på clustis3. http://en.wikipedia.org/wiki/Sun_Grid_Engine
  • Hvis det finnes logg fra IDI Open over submissions eller no, så kan vi kjøre en simulasjon på det nye systemet når det dukker opp. Evt føre logg under NM for å bruke det som simulasjon. Så kan man evt kjøre loggen flere ganger i parallel for å stresse systemet enda mer.



2009/05/23 13:43, Hallgeir Lien