Pooling vs. Notifikation ?

Du mener vist ikke pooling men polling.

Det er to forskellige ting. Pooling er hvis du har en pool af resourcer
(f.eks. database connections) som du deler. Polling er hvis du periodisk
requester det samme for at se om det har ændret sig.

Den store fordel ved polling er at det er nemt at kode. Du requester bare med
et fast interval. Det er nemt. Det er imidlertid også meget tungt, fordi
hvis noget kun bliver opdateret få gange om dagen og man poller med 5 sekunder
interval, så er langt størstedelen af arbejdet jo spildt.

Notifikation er lang smartere, da man kun laver noget når der er grund til
det. Der er en masser patterns som baserer sig på notifikation. Problemet
er at det kræver en del kode - og at det kræver at man har kontrol
over begge sider.

Kontrol over begge sider..?? Kan du præcisere lidt mere..??

Grunden til jeg spørger, er at min gruppe og jeg i morgen skal op til eksamen. Vi har lavet et spil der bruger polling, og vi forventer at de vil gå til benet og kræve at vi forklare hvorfor vi ikke har brugt notifikation..

Det vi har lavet er et ordspil, hvor klienten hele tiden tjekker om der er kommet nye ord eller spillere....

-Anders

http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

Observer pattern ... her vil man kunne få klienten til at tilmelde sig en service der er defineret på en server eller i jeres tilfælde måske en gameController. i stedet for at jeres klient skal stå og tjekke om der er sket nye ting som den eventuelt kunne være interesseret i, ja så får den automatisk besked fra serveren, eller hvem der nu håndterer dette job.

smok

"Kontrol over begge sider" dækker over problemet med hvis den anden
part (det der skal notificere din kode) ikke er noget man kan rette i.

Hvis f.eks. det er noget man har købt uden kildekode eller hvis
koden tilhører en anden afdeling som ikke er samarbejdsvillig eller
hvis det bruger en anden teknologi som ikke snakker godt sammen
med dit program.

Umiddelbart lyder et spil som noget der egner sig til notifikation.

Men jeres bedste forsvar vil nok være:
  - det er ikke et reelt performance problem i jeres setup (så skal
    I naturligvis være sikker på at det ikke er det !)
  - koden er simplere uden

Læs evt. lidt på notifikation (f.eks. smoks link til en JavaWorld
artikel om observer pattern), så I kan forklare mundtligt, hvordan
I kunne have lavet notifikation.

Efter min mening er det ikke nogen skam at have noget simpelt der virker plus
ideer til hvordan det kunne forbedres.

Hvad siger du til dette argument :

Vi har valgt polling pga. at det er mere tilfældigt end notifikation.. Dvs. at det der altid notifiseres i samme rækkefølge ved notifikation. Ved polling, som vi har lavet med en tråd, er det mere "tilfældigt" hvornår de enkelte klienter opdatere... Så rækkefølgen er derved ikke altid den samme, og det gør så spille mere fair, i og med det ikke altid er den samme spiller der får den opdaterede ordliste først...

??

-Anders

Nu kunne man godt lave en notifikation som notificerede i tilfældig
rækkefølge.

Men det vil selvfølgelig kræveyderligere noget kode.

Det er et argument.

Men jeg tror ikke at jeg ville bruge det som hoved-argument.

[men da jeg ikke ved hvad du læser, hvilken eksamen du skal til,
hvad pensum er eller hvem lærer er - så kan du med en vis ret
mene at du ved bedre !]

Jo mere jeg tænker over det poll=random argument jo mere skeptisk
bliver jeg.

Hvis alle poller med konstant interval vil det jo i virkeligheden ikke
være særligt tilfældigt.

Hvis jeg har forstået a-torsten ret, så er det noget med, at der er nogle ordlister, som ind i mellem bliver opdateret.  Hvis der f.eks. er 10 spillere, og de bliver pollet en gang i minuttet, men før hver polling af en spiller, bliver der pollet for opdatering af ordlisten - ja, så vil den næste spiller få den opdaterede ordliste, mens de 9 andre vil fortsætte med den liste, de allerede har.  På den måde bliver der noget tilfældigt i, hvem af spillerne, som først får den opdaterede liste.
  Hvis denne randomisering skal være retfærdig, så skal der være et lige stort interval mellem pollingen af de enkelte spillere.  Hvis det tager 1 sekund at polle en spiller, så vil der med 10 spillere og polling en gang pr. minut være 50 sekunder, hvor der kan komme nye opdateringer til fordel for den første spiller.  Men de øvrige spillere får opdateringen op til 10 sekunder senere - en rimelig forsinkelse.  Hvis der derimod kommer en opdatering lige efter pollingen af den første spiller, så får de ni andre spillere opdateringen inden for 9 sekunder, mens den første spiller skal vente et minut.  Ikke særligt retfærdigt.
  Så hvis der skal være retfærdighed i tilfældighederne, så skal spillerne enten polles med samme indbyrdes forsinkelse, eller også skal de polles i tilfældig rækkefølge.

Eller også har jeg ikke forstået a-torsten... :-)

greatdane => dette ville så kunnes forebygges ved snedig brug af serverens klokkeslæt... ;)

så hvis requestet kom kl 18:47:33 satte den refresh-tiden til 27 sek, og hvis det kom 18:47:11 satte refresh-tiden til 49 sek... altså automatisk lave det så en evt differance bliver udlignet hved hver refresh...

just my 2 cents...

Morten