Manual

Manual
des Online Betting System BetGetter und Viveo
Version:
Kontext:
Autoren:
Betreuer:
Kontakt:
Datum:
1.0
Laborprojekt "Online Betting System", Distributed
Computing Group, ETH Zürich, 2003/04
Gregor Bättig, Stefan Bollmann, Andreas Diener,
Fabian Nart und Christian Wassmer
Ruedi Arnold
[email protected]
26. Februar 2004
Inhaltsverzeichnis
1.
2.
Einleitung........................................................................................................ 4
Architektur ...................................................................................................... 5
2.1. Übersicht ................................................................................................. 5
2.2. BetGetter ................................................................................................. 5
2.3. Viveo....................................................................................................... 6
3. Spiellogik ........................................................................................................ 8
3.1. Anleitung................................................................................................. 8
3.2. Quoten................................................................................................... 10
3.3. Future Work .......................................................................................... 11
4. Testwoche ..................................................................................................... 14
4.1. Einleitung.............................................................................................. 14
4.2. Setting ................................................................................................... 14
4.3. Probleme ............................................................................................... 14
4.4. Statistiken.............................................................................................. 15
4.5. Akzeptanz beim Publikum.................................................................... 18
4.6. Persistenz .............................................................................................. 19
4.7. Performancetest..................................................................................... 20
5. Installation / Konfiguration........................................................................... 21
5.1. Installation der Entwicklungs-Umgebung ............................................ 21
5.2. Eclipse-Einstellungen ........................................................................... 21
5.3. Konfiguration des Systems ................................................................... 21
5.4. Starten des Systems............................................................................... 22
5.5. Daten einlesen....................................................................................... 22
Anhang A: Interfacedefinition Frontend – Backend............................................. 24
Anhang B: Datenmodell ....................................................................................... 27
Anhang C: DNS Round-Robin und Dynamic DNS.............................................. 28
-2-
-3-
1. Einleitung
Seit Anbeginn der Zeit ist Wetten ein Bestandteil der menschlichen Kultur.
BetGetter und Viveo sind Komponenten eines Online Betting System, das den
Gedanken des Wettens in das digitale Zeitalter transferiert. Dieses, als Teil eines
Laborprojektes konzipierte System, ist verteilt, ausfallsicher und lastbalanciert
implementiert. Sinn dieses Dokumentes ist es, dem späteren Betreiber und
Weiterentwickler einen technischen Überblick zu geben.
Einzelheiten zur Implementierung finden sich im folgenden Kapitel.
Anschliessend, in Kapitel 3, wird die Spiellogik beschrieben. Information über
Wettquoten sowie künftige Verbesserungsmöglichkeiten werden ebenfalls in
diesem Kapitel behandelt. Kapitel 4 beinhaltet die Resultate einer einwöchigen
Testwoche sowie die Auswertung einer anschliessenden Umfrage. Hinweise zu
Installation und Konfiguration finden sich in Kapitel 5. Diagramme sowie
Definitionen sind in den Anhängen zu finden.
-4-
2. Architektur
Aus Gründen der Benutzbarkeit lag es nahe, einer Webapplikation den Vorzug zu
geben. Im Folgenden wird die Architektur des Online Betting System
beschrieben.
2.1.
Übersicht
Im Sinne einer Wiederverwendbarkeit für verschiedene Sportanlässe wurde das
System in einen generischen Backend-Teil und einen anlass-spezifisches
Frontend-Teil aufgeteilt. Ersterer, genannt BetGetter, bietet allgemeine
Funktionalitäten für die Verwaltung von Wetten, Spielern, Spielen und
dergleichen an. Viveo, die graphische Benutzeroberfläche, wurde für die
Testwoche entwickelt und auf Eishockey-Spiele der National Hockey League
NHL [NHL] ausgelegt.
Viveo greift auf die Funktionalität von BetGetter über eine wohldefinierte
Schnittstelle, das ApplicationBean, zu. Abbildung 1 stellt eine schematische
Übersicht der genannten Komponenten dar. In Anhang A ist die gesamte
Schnittstellenfunktionalität des ApplicationBean zu finden.
Abbildung 1 Übersicht der Architektur von BetGetter
Das Online Betting System läuft als Webapplikation im Web-Application-Server
Tomcat [Tomcat], welcher auch gleichzeitig als Web-Server fungiert.
Java Server Pages (JSP) generieren die im Webbrowser des Benutzers
dargestellte HTML-Seite. Dazu wird über das ApplicationBean auf die Spiellogik
zugegriffen. Der Forschungsprototyp Clippee [Clippee] stellt die Verteilung der
Spieldaten sicher.
2.2.
BetGetter
BetGetter, zu Deutsch "WettErreger", ist in Java realisiert. Eine auf das
Wesentliche beschränkte Darstellung in UML ist in Anhang B zu finden.
-5-
2.2.1.
Verteilte Datenhaltung
Sämtliche im System gehaltenen Daten-Objekte erben von der Klasse
DataObject aus dem Package clippee. Clippee ist eine Client-Peer Architektur,
welche Dienste ähnlich einem Gruppenkommunikationssystem anbietet.
Das Kernstück des Systems bildet ein Objekt der Klasse BetGetterPeer, welches
als Singleton instanziiert wird. Beim Erstellen versucht ein solcher
BetGetterPeer sich zuerst mit anderen aktiven Peers als Joining-Peer zu
verbinden. Die IP-Adressen potentieller Partner-Peers sind in einem
Konfigurations-File zu definieren. Falls keine Verbindung zu Stande kommt,
führt er die Initialisierungsroutine als First-Peer aus und wartet auf eingehende
Verbindungen anderer Peers.
2.2.2.
Lokale Datenreferenzierung
Um lokal über sämtliche Datenobjekte wie User, Match, etc. iterieren zu
können, werden Referenzen auf diese in Hash-Maps abgelegt. Diese Hash-Maps
werden mittels Observer-Pattern aktuell gehalten.
2.2.3.
Filter
Um Matches und Wetten nach bestimmten Kriterien filtern zu können, wird das
Composite-Pattern benutzt. So können Filter über verschiedene Dimensionen wie
Zeit, Team oder Wetten zu einem einzigen Filter kombiniert werden.
2.3.
Viveo
Viveo ist der von Aussen sichtbare Teil des Online Betting System. Diese
graphische Oberfläche wurde durch mehrere *.jsp Files umgesetzt, welche den
hohen Anforderungen des strikten XHTML-Standards von W3C [W3C] gerecht
werden. Für die Formatierung der Seiten wurden Cascading Style Sheets (CSS)
verwendet. Es wurde auf eine intuitiv bedienbare, stilvolle Gestaltung der
Benutzeroberfläche Wert gelegt.
-6-
Abbildung 1: Aufbau einer Java Server Page
Die Oberfläche besteht aus verschiedenen
zusammenstellbare Einheiten bilden.
JSPs,
welche
modularartig
Alle Seiten, die auf die Backend-Funktionaliät von BetGetter zugreifen, tun dies
über das ApplicationBean, welches pro Tomcat-Instanz genau einmal vorhanden
ist. Um Wetten platzieren zu können, muss sich ein User einloggen. Zu diesem
Zeitpunkt wird auf der Serverseite ein SessionBean erzeugt. Tomcat verwaltet
verschiedene User Sessions mit Hilfe von Cookies.
-7-
3. Spiellogik
3.1.
Anleitung
3.1.1.
Ziel des Online Betting System
Es ist das Ziel des Spiels, durch geschicktes Wetten das Startguthaben zu
vermehren. Dabei ist es möglich, in Tippgemeinschaften, so genannten Cliquen,
als Team zu reüssieren. Somit werden Ranglisten für Einzelspieler als auch für
Cliquen geführt.
•
Es gewinnt derjenige Einzelspieler, der am Ende des Spieles die meisten
Punkte auf seinem Konto hat.
•
Es gewinnt diejenige Clique, deren Mitglieder am Ende des Spieles im
Durchschnitt die meisten Punkte haben.
Besitzt ein Spieler kein Guthaben mehr, ist für ihn das Spiel vorzeitig beendet.
3.1.2.
Rangliste
•
Es erscheinen nur Spieler, die mindestens eine Wette abgeschlossen haben,
in der Rangliste. Die Rangliste basiert auf dem Guthaben der Spieler.
•
Es erscheinen nur Cliquen auf der Cliquen-Rangliste, die mindestens zwei
Mitglieder haben, welche bereits gewettet haben. Die Rangliste basiert auf
der Punktezahl einer Clique, welche dem Durchschnitt der Guthaben ihrer
Mitglieder entspricht.
3.1.3.
Punktekonto
•
Jeder Spieler erhält zu Beginn ein Startguthaben von 1000 Punkten.
•
Wenn ein Spieler keine Punkte mehr auf seinem Konto hat, kann er keine
Wette mehr platzieren.
3.1.4.
Wetten
•
Pro Spiel kann eine Wette abgeschlossen werden.
•
Es kann auf Heimsieg, Auswärtssieg oder Unentschieden gewettet werden.
Jedes dieser Ereignisse besitzt eine Gewinnquote.
•
Ein Spieler kann nicht mehr Punkte setzen als er auf seinem Konto hat.
•
Der maximale Einsatz pro Spiel beträgt 3000 Punkte.
•
Der Wetteinsatz wird sofort nach Wettabschluss vom Konto abgezogen.
•
Es werden die Resultate am Ende des Spiels (nach einer eventuellen
Verlängerung) ausgewertet.
•
Bei gewonnener Wette wird der Wetteinsatz multipliziert mit der
entsprechenden Gewinnquote auf das Konto gutgeschrieben.
•
Vorsicht! Einmal abgeschlossen, kann eine Wette nicht mehr geändert
werden!
-8-
3.1.5.
Cliquen
Eine Clique ist eine Gemeinschaft von Spielern. Sowohl die Mitglieder einer
Clique untereinander, als auch die verschiedenen Cliquen können sich mittels der
Ranglisten vergleichen.
Jeder Spieler kann beliebig viele Cliquen gründen und bestehenden Cliquen
beitreten. Des Weiteren lassen sich alle Cliquen und ihre Mitglieder betrachten.
Der Gründer einer Clique ist zugleich der Cliquen-Boss und kann neue Mitglieder
akzeptieren oder ablehnen.
3.1.6.
Mögliche Aktionen
Wetten abschliessen
Wähle in der Navigation Wette abschliessen. Die angezeigten Spiele kannst du
nach Team und/oder Zeit filtern. Um eine Wette abzuschliessen, setze auf das
gewinnende Team (1 / 2) oder auf Unentschieden (x) und gebe den Wetteinsatz
ein. Schliesse die Wette durch Klicken des "Ok" Buttons ab.
Vorsicht! Eine Wette kann nicht mehr geändert werden.
Abbildung 2: Wette abschliessen
Eigene Wetten betrachten
Um die eigenen Wetten auf noch nicht begonnene Spiele zu betrachten,
wähle in der Navigation Meine Wetten. Ist das Spiel bereits beendet,
lassen sich unter Meine Resultate die Ergebnisse betrachten. Die Anzeige
lässt sich nach Teams und/oder Zeit filtern.
Clique gründen
Wähle in der Navigation Cliquen und gebe unter Neue Cliquen gründen
einen neuen Cliquenamen ein.
Clique beitreten
Wähle in der Navigation Cliquen und wähle unter Clique beitreten den
Cliquenamen. Bestätige die Eingabe durch Drücken des OK Buttons. Falls
dich der Leader der gewählten Clique akzeptiert, wirst du in die Clique
aufgenommen. Sind alle Spiele vorbei, kann man keiner Clique mehr
beitreten.
Eigene Cliquen anzeigen
Wähle in der Navigation Cliquen. Durch Anklicken der Clique unter
Meine Cliquen siehst du die Mitglieder der Clique sowie deren Rangliste.
Hier kannst du auch neue Mitglieder einladen. Als Clique Leader kannst
Du zudem die Anträge um Clique-Beitritt von Spielern akzeptieren oder
ablehnen.
Andere Cliquen anzeigen
-9-
Wähle in der Navigation Cliquen und wähle unter Clique suchen den
Cliquenamen. Bestätige die Eingabe durch Drücken des OK Buttons. Nun
kannst Du die Mitglieder der Clique und deren interne Rangliste
betrachten.
3.2.
Quoten
Ein Wettsystem mit Quoten, welche für jedes Spiel und jeden Ausgang gleich
sind (wie in der Testwoche), verleitet den Spieler dazu, sein ganzes
Punktvermögen auf ein Spiel – nämlich das “sicherste” - zu setzen. Das
Wettsystem verliert dadurch an Spannung. Mit einer variablen Quote würde man
nicht mehr “automatisch” seine Punkte auf das “sicherste” Spiel setzen, sondern
dort, wo man meint, eine hohe Quote zusammen mit einer verhältnismässig hohen
Gewinnchance zu haben.
Im Folgenden sind mehrere Arten, wie man solche Quote erhalten könnte, kurz
beschrieben. Im Allgemeinen wird der eingesetzte Betrag im Falle eines
Gewinnes multipliziert mit der Quote ausbezahlt.
In der Endversion von BetGetter sind statische Quoten implementiert.
3.2.1.
Statische Quoten
Statische Quoten werden in den meisten Fällen von einem professionellen
Buchmacher bestimmt. Dieser muss dabei über ein grosses Sportwissen sowie
Erfahrung mit Wettsystemen verfügen, damit er die Spielausgänge
beziehungsweise das Wettverhalten der User möglichst genau voraussagen kann.
Klar favorisierte Mannschaften erhalten deshalb tiefe Quoten - teilweise fast eine
Quote von eins. Klare Aussenseiter hingegen können teilweise sehr hohe Quoten
erhalten. So kann ein Spieler auswählen, ob er ein grosses Risiko (mit
entsprechender Gewinnchance) eingehen will und auf einen Aussenseiter setzt
oder ob er einen relativ sicheren, jedoch kleinen Gewinn einfahren möchte. Das
macht das System spannender. Das Problem ist, dass die Punktemenge, die sich
im Spiel befindet, immer weniger wird, da die beruflichen Buchmacher die
Quoten so bestimmen, dass im Schnitt für den Wettsystembetreiber ein Gewinn
herausschaut.
Der Vorteil hingegen ist, dass dieses System klar und gut verständlich ist. Da die
Quoten fix sind, kann der Wetter sie nicht durch manipulierte Wetten
beeinflussen, wie das in einem System mit dynamischen Quoten möglich ist.
3.2.2.
Dynamische Quoten
Bei den dynamischen Varianten werden die Quoten on-the-fly anhand des
bisherigen Wettverhaltens der Benutzer berechnet. Dabei beeinflussen eben
platzierte Wetten die Quoten für die nachfolgenden Wetten. Im Allgemeinen sinkt
nämlich eine Quote, wenn ein Wetter einen relativ hohen Betrag auf bestimmtes
Ergebnis setzt. Dies kann der gewiefte Wetter dazu ausnützen, die Quoten für sein
Hauptkonto positiv zu manipulieren. Um dies zu erreichen, führt er ein oder
mehrere Nebenkonti, die für ihn nur dazu da sind, fiktive Wetten abzuschliessen,
welche eben die Quoten für ihn positiv beeinflussen. Dies wird erst unterbunden,
wenn um echtes Geld gespielt wird.
- 10 -
3.2.3.
System „Jackpot“
Bei diesem System kommen alle Einsätze eines Spiels in einen Jackpot. Nach
dem Spiel wird dann der Jackpot unter den Gewinnern proportional zu ihren
Einsätzen verteilt. Der grosse Vorteil dieses Systems ist, dass man die sich im
Spiel befindende Punktemenge steuern kann. Der Veranstalter kann nämlich
immer einen gewissen Teil vom Jackpot wegnehmen oder dazutun. Der Nachteil
ist, dass die Benutzer nie genau wissen können, wie ihre Gewinne sein werden.
3.2.4.
System „Wettbörse“
Einen interessanten Ansatz bietet eine Wettbörse. Anstatt dass ein Buchmacher
alle Quoten bestimmt, lässt man das die Wetter selber tun. Dies ist ein neuer
Ansatz und es gibt Anzeichen dafür, dass solche Wettbörsen gross im Kommen
sind. Der Unterschied besteht darin, dass nun nicht mehr der Buchmacher eine
Wette anbietet, sondern es die Benutzer selber tun.
Zum Beispiel bietet Alice eine Wette “Tipp 1, 100 Punkte, Quote 2.2” an. Bob
sieht dieses Wettangebot und geht darauf ein. Das heisst, Bob überweist Alice 100
Punkte in der Meinung, dass Tipp 1 tatsächlich eintritt. Alice hatte mit diesem
Wettangebot nämlich genau das Gegenteil behauptet und bot jedem Wetter an,
mit 100 Punkten gegen ihre Behauptung anzutreten. Behält sie Recht, kann sie die
Punkte von Bob behalten – ansonsten muss sie Bob den Einsatz multipliziert mit
der Quote überweisen. Alice war somit für diese Wette der Buchmacher. Bei
einem anderen Spiel kann es gerade umgekehrt sein.
Dieses System bietet ein grosses Interaktionspotential und ist deshalb
insbesondere für Zocker geeignet. Es braucht jedoch einen gewissen Grundstock
an Spielern, vor allem solche, die sich im Sport auskennen und bereit sind, häufig
Wetten anzubieten.
3.3.
Future Work
Auch wenn wir in der Testwoche ein grundsätzlich positives Echo erhalten haben,
sehen wir noch einige Verbesserungsmöglichkeiten.
3.3.1.
Objekte löschen
Durch die Verwendung von Clippee sahen wir uns mit dem Problem konfrontiert,
dass Objekte nicht gelöscht werden können. Dies ist nicht nur unschön, sondern
kann auch zu unangenehmen Folgen führen. Zum Beispiel können Benutzer nicht
gelöscht werden, welche einen unanständigen Nick führen oder das System
missbrauchen. Oder – was noch schlimmer ist – wenn der Administrator ein Spiel
eingibt, welches nicht existiert, kann er es nicht mehr aus dem System löschen.
Demzufolge wird es auf der Liste der zu wettenden Spiele aufgeführt ohne dass
das Spiel stattfindet.
Mögliche Lösungen wären:
•
•
jedes Objekt hat ein Valid-Flag, welches anzeigt, ob das Objekt noch
gültig oder gelöscht ist
Clippee erweitern, so dass Objekte gelöscht werden können
3.3.2.
Dynamische Quoten
Ein Problem der ersten Lösung des Spiels war, dass die Quoten für alle Spiele
gleich sind. Weil nicht auf alle Spiele gesetzt werden muss, kann ein gewiefter
- 11 -
Spieler alles Geld auf diejenigen Spiele setzen, in welchen er die grösste
Gewinnwahrscheinlichkeit hat.
Momentan werden die Quoten vom Administrator eingegeben. Die Grundlage
dazu könnten Berechnungen anderer Wettsysteme sein. Durch die statischen
Quoten ist für jeden Benutzer bei der Abgabe seiner Wette sein möglicher
Gewinn ersichtlich. Hingegen würden dynamische Quoten berücksichtigen, wie
andere Spieler die Gewinnchancen der Teams einschätzen. Das Problem ist
jedoch, dass dabei die Quote bei Wettabgabe und Spielbeginn unterschiedlich ist.
Somit bleibt die Quote nicht transparent für den Wettenden. Mögliche Lösungen
wären dafür:
•
keine Anzeige der Quoten bei der Wettabgabe:
Dadurch kann der Benutzer aber nicht abschätzen, wie viel er gewinnen
kann (ist also Lotterie)
•
dynamische Quote in Wette einbinden
Der Gewinn basiert auf der zur Wettabgabe geltenden dynamischen
Quote. Dadurch muss jedes Wett-Objekt um die gültige Quote erweitert
werden. Jeder Spieler erhält also je nach Zeitpunkt der Wettabgabe eine
andere Quote.
3.3.3.
Spielmodi
Je nach Art des Spielmodus ist ein Unentschieden nicht möglich (Cup-Spielen,
Viertel-, Halb-, Final...). Dies wird zurzeit noch nicht berücksichtigt.
3.3.4.
Wetten ändern
Insbesondere bei dynamischen Quoten will ein Spieler aufgrund von neuen
Informationen seine Wette ändern oder sogar löschen können. Ob Löschen erlaubt
werden soll, ist eine ideologische Frage. Schliesslich erlauben es reale Systeme
wie TOTO auch nicht. Ein Ändern hingegen macht durchaus Sinn, zumindest bis
zu Spielbeginn.
3.3.5.
Mehrere Wetten mit einem Klick abschliessen
Auf einer JSP-Seite werden mehrere Matches angezeigt. Deshalb sollte auch das
Abschliessen von mehreren Wetten per Mausklick möglich sein.
3.3.6.
Passwort vergessen
Ein Benutzer, welcher sein Passwort vergessen hat, sollte die Möglichkeit haben,
sich per Mausklick sein Passwort an die von ihm bei der Registrierung
angegebene Email-Adresse schicken zu lassen.
3.3.7.
Serverausfall
Beim Ausfall eines Servers funktioniert der Zugriff auf einen anderen Server
innerhalb der ETH dank Round-Robin gut. Hingegen besteht aufgrund von
Caches in anderen DNS-Servern das Problem, dass möglicherweise auf einen
nicht funktionierenden Server zugegriffen wird. Deshalb sollte mittels DDNS
(Dynamic DNS) der entsprechende Server aus dem DNS-Eintrag gelöscht
werden. Siehe dazu auch Anhang C: DNS Round-Robin und Dynamic DNS.
- 12 -
3.3.8.
User-Session
Eine User-Session geht verloren, wenn der entsprechende Peer ausfällt. Eine
mögliche Lösung ist über ein Session-Objekt die entsprechenden Daten in Clippee
zu speichern.
3.3.9.
Sollte man Pleite gehen können?
Dies ist eine noch zu klärende Frage. Unsere Überlegungen diesbezüglich sind die
folgenden:
•
•
bei echtem Geld: ja. Ist das Geld aufgebraucht, ist ein Platzieren von
Wetten nicht mehr möglich. Hingegen kann zusätzliches Geld einbezahlt
werden und dann weiter gewettet werden.
bei virtuellen Geld: wenn das Ziel ist, die Benutzer oft auf die Homepage
zu locken, sollte ein Pleite gehen vermieden werden. Dies ist jedoch nicht
leicht zu erreichen. Weil das Ziel jedes Spielers zu gewinnen ist, wird er
täglich sein ganzes Geld wetten, um überhaupt eine Chance zu haben. Ein
Maximaleinsatz pro Wette hilft nur bedingt. Eine umsetzbare Lösung
scheint deshalb nicht zu existieren.
- 13 -
4. Testwoche
4.1.
Einleitung
Gegen Ende des Projektes wurde eine Testwoche durchgeführt, bei der das Online
Betting System (unter dem Namen Viveo NHL) öffentlich zugänglich gemacht
wurde. Ziel war es, das System im Betrieb zu beobachten und in verschiedenen
Bereichen Test durchzuführen und damit den Beweis der Funktionstüchtigkeit des
Systems zu erbringen. Besonderes Augenmerk wurde dabei auf folgende Punkte
gelegt:
• Konsistenz der (redundant) verteilten Daten
• Performance des Systems
• Lastverteilung
• Statistische Auswertung des Benutzerverhaltens
• Akzeptanz des Systems bei den Benutzern
In den meisten Punkten konnten die Erwartungen erfüllt oder sogar übertroffen
werden.
4.2.
Setting
Das System war während der Testwoche auf drei Rechner verteilt, auf denen je
eine Tomcat-Instanz lief, die je eine Instanz der Webapplikation und damit einen
Clippee-Peer enthielt. Die drei Rechner konnten je mit eigener IP angesprochen
werden, der DNS-Server war aber so eingerichtet, dass Requests auf viveo.ethz.ch
nach dem Round-Robin-Verfahren auf die drei IPs verteilt wurden.
4.3.
Probleme
Während der Testwoche gab es verschiedene Probleme zu bewältigen, welche
zum grössten Teil nicht-technischer Natur waren. Diese Art von Problemen wurde
schon in kleineren Testläufen zuvor beseitigt.
4.3.1.
Browser-Kompatibilität
Obwohl die generierten HTML-Seiten allesamt dem strikten XHTML-Standard
von W3C [W3C] entsprachen, gab es insbesondere bei Mac-Browsern Probleme
mit der Darstellung. So war zum Beispiel auf Safari kein Login-Button sichtbar.
Alle bekannten Probleme dieser Art sind mittlerweile behoben.
Darstellungsprobleme gab es des Weiteren auf Mozilla/Netscape, welche jedoch
bereits im Verlaufe der Testwoche behoben wurden.
4.3.2.
Rechtliches
Ein aufmerksamer Assistent eines ETH-Institutes wies darauf hin, dass solche
„Glückspiele“ gemäss des Schweizerischen Lotteriegesetzes [Lotterie] nicht
erlaubt seien. Doch da es sich bei Viveo NHL um einen nicht-kommerziellen Test
im Rahmen eines Laborprojektes handelte, dürfte der Test legal gewesen sein.
Auch die Verwendung der NHL und deren Logos war nicht gestattet gewesen.
Um diese legal zu verwenden, bräuchte man deren Einverständnis, welche nicht
vorlag.
- 14 -
Ein weiteres rechtliches Problem waren die Regeländerungen während der
Testwoche. Einmal durfte ein Mitglied der DCGDolphins gewinnen, dann wieder
nicht und schliesslich gewann dann doch ein Mitglied dieser Clique die
Einzelwertung in Übereinstimmung mit den am Schluss gültigen Regeln. Für
einige Verwirrung sorgte auch die Regeländerung nach den ersten Spielen – man
durfte nur noch maximal 3000 Punkte pro Spiel setzen.
4.3.3.
Peinlich …
In diese Kategorie gehört die Tatsache, dass man sich während einer kurzen Zeit
ohne Passwort als Administrator einloggen konnte. Dies deshalb, weil die
entsprechende Stelle im Code (dort wo das Passwort überprüft wird)
auskommentiert war und durch einen Standardwert ersetzt wurde.
In dieselbe Kategorie gehört auch die Tatsache, dass sämtliche einen Tag zu früh
angesetzt wurden. Das Hauptverschulden lag jedoch bei den Betreibern von
[eishockey.com], welche die Zeitverschiebung falsch interpretierten. Noch vor
den ersten Spielen konnte dieser Fehler korrigiert werden.
4.4.
Statistiken
Im folgenden Abschnitt werden einige interessante Zahlen und Fakten zur Viveo
NHL Testwoche dargestellt.
4.4.1.
Benutzer
Total meldeten sich 152 Benutzer im System an. Davon platzierten 119
mindestens eine Wette und kamen somit in die Einzelrangliste. Insgesamt gab es
etwas mehr als Tausend Logins. Am meisten Logins (233) pro Tag gab es am Tag
nach der Nacht, in welcher die ersten Spiele stattgefunden haben. Dies war der
Mittwoch, 21. Januar. An diesem Tag gab es auch den Stundenrekord (zwischen
17 und 18 Uhr) von 33 Logins.
Abbildung 3 zeigt den Verlauf der Logins. Enttäuschend sind die ungefähr 50
Logins nach den letzten Spielen. Offenbar war das Wettsystem für viele Benutzer
nicht mehr interessant, da sie keine Gewinnchancen mehr hatten.
- 15 -
Abbildung 3: Anzahl Logins pro Tag. Die Testwoche dauerte vom 21. bis 24. Januar.
Es wurden 19 Cliquen gegründet. Die Durchschnitts-Clique hatte 3.8, die grösste
8 und die kleinsten Cliquen 2 Mitglieder.
4.4.2.
Wetten
Die Benutzer setzten in 1'306 Wetten insgesamt 509'649 Punkte. Dabei war jede
zweite Wette (50.2 %) erfolgreich. Der aufsummierte Gewinn beträgt 770'604
Punkte. Dabei verteilten sich die Wetten gut auf die verschiedenen Spielnächte,
wie Abbildung 4 zeigt. Der Abwärtstrend wurde am letzten Tag korrigiert, indem
wieder vermehrt gewettet wurde. Offenbar wollten es viele Benutzer noch einmal
wissen. Durchschnittlich platzierten die Benutzer 8.6 Wetten bei einer
Standardabweichung von ungefähr 3 und einem Median von 6. Abbildung 5 zeigt
wie viele Benutzer wie viele Wetten abgeschlossen haben.
- 16 -
Abbildung 4: Durchschnittliche Anzahl Wetten auf ein Spiel für jede Spielnacht
Abbildung 5: Anzahl Wetten pro Benutzer
4.4.3.
Verteiltheit
Wie Abbildung 6 zeigt, funktionierte das DNS-Round-Robin sehr gut. Die Logins
verteilten sich gleichmässig auf alle drei eingesetzten Peers bei einer
Standardabweichung von 12.4 Logins beziehungsweise 1.2 Prozentpunkten. Und
somit auch alle anderen Aktionen, welche ein Benutzer ausführen konnte, wie
eine Wette platzieren. Denn einmal eingeloggt, verblieb ein Benutzer immer auf
dem gleichen Peer bis er sich wieder neu einloggte. Somit wurde auch eine
ausgeglichene Lastverteilung erreicht. Denn die Berechnungen für die neuen
Daten wurden allesamt lokal auf einem Peer durchgeführt.
- 17 -
wllap13 wllap14 wllap15
#login 318
337
348
%login 31.7%
33.6%
34.7%
Abbildung 6: Verteilung der Logins auf die einzelnen Peers
4.5.
Akzeptanz beim Publikum
Neben vereinzelten Stimmen materialisierte sich die Stimmung bei den Benutzern
des Systems vor allem in der Auswertung einer Umfrage, die am Ende der
Testwoche durchgeführt wurde. Die Teilnahme war nicht zwingend.
4.5.1.
Auswertung der Umfrage
Teilnehmer: 29 von 119 aktiven Benutzern (24%)
Weiterführung von Viveo NHL
• JA: 17 (59%)
• NEIN: 3 (10%)
• VIELLEICHT: 9 (31%)
Ein System für die Europameisterschaft in Portugal 2004
• JA: 18 (62%)
• NEIN: 4 (14%)
• VIELLEICHT: 7 (24%)
Etwas vermisst:
• JA: 12 (41%)
• NEIN: 17 (59%)
(nicht aussagekräftig, da einige Neinsager unter Punkt 6 doch noch
Verbesserungsvorschläge gemacht haben)
Was wurde vermisst:
• Quoten: 9 Nennungen
• Ändern einer einmal abgeschlossenen
Wette: 1 Nennung
• Rangliste aussagekräftiger machen (z.B.
durch Anzeigen der eingesetzten Punkte): 1 Nennung
• Mindesteinsatz für jedes Spiel (z.B. 20%
des Maximal-Einsatzes): 2 Nennungen
• Cliquen: Nicht der Durchschnitt aller,
sondern nur der besten sollte relevant sein: 1 Nennung
• Chat-Funktionen, Messaging: 1 Nennung
• Mehr Angaben zu Matches (Overtime...): 1 Nennung
• NLA-Viveo: 1 Nennung
• Allgemein mehr Möglichkeiten: 2 Nennungen
Note fürs Design
• Abgegebene Noten: 29
• Tiefste Note: 1.00 (2x)
- 18 -
•
•
•
•
Höchste Note: 6.00 (2x)
Häufigste Note: 5.00 (14x)
Durchschnitt: 4.21 (mit Streichnoten: 4.30)
Alles: 2x1 1x2 3x3 7x4 14x5 2x6
Note Allgemein
• Abgegebene Noten: 28
• Tiefste Note: 1.00 (1x)
• Höchste Note: 6.00 (3x)
• Häufigste Note: 5.00 (17x)
• Durchschnitt: 4.64 (mit Streichnoten: 4.73)
• Alles: 1x1 0x2 2x3 5x4 17x5 3x6
Bemerkungen
• Explizites Kompliment: 4 Nennungen
4.6.
Persistenz
Clippee hält alle Daten im Arbeitsspeicher. Fällt ein Peer aus, verliert er daher
seine Daten. Da alle Daten in allen Peers repliziert werden, sind sie in den noch
laufenden Peers weiterhin vorhanden. Ist der ausgefallene Peer wieder
einsatzbereit und verbindet sich mit den laufenden Peers, so werden die Daten
wieder abgeglichen und sind wieder überall vorhanden.
Sind jedoch einmal alle Peers zum selben Zeitpunkt ausgefallen (gleichzeitiger
Ausfall oder einer nach dem anderen), so sind die Daten ganz verloren. Dies ist
für ein System wie BetGetter/Viveo natürlich inakzeptabel, weshalb beschlossen
wurde, Clippees Daten zusätzlich auf der Festplatte zu speichern.
Implementiert wurde dies durch Loggen aller Änderungen von Clippee-Daten,
und zwar jeweils lokal auf demjenigen Peer, von welchem die Änderung ausging.
Es existiert daher auf jedem Peer ein aktuelles Logfile, welches von Peer zu Peer
inhaltlich verschieden ist. Fallen nun tatsächlich alle Peers gleichzeitig aus, so
müssen lediglich die Logfiles aller Peers wieder eingelesen werden, um das
System wieder auf den Stand vor dem Ausfall zu bringen.
Fällt ein einzelner Peer aus, so wird beim erneuten Einsatz ein frisches Logfile
erstellt, wobei das alte Logfile weiter benötigt wird. Es ist daher zu beachten, dass
beim Einlesen alle (unter Umständen mehrere pro Peer) Logfiles eingelesen
werden müssen, welche seit dem Start des Systems oder dem letzten Totalausfall
desselben angelegt wurden.
Die konkrete Implementation verwendet eine Erweiterung des DataManagers von
Clippee, namentlich betgetter.LoggingDataManager, welche bei jedem Aufruf
der Methode updateObjectGlobally(DataObject o) das veränderte
DataObject loggt. Die implementierte Persistenz ist daher unabhängig von
BetGetter und kann von jedem auf Clippee aufbauenden System eingesetzt
werden.
Weiters gibt es die Möglichkeit, eine Momentaufnahme des Clippee-Datenraumes
zu speichern. Hier werden alle Daten in ein einzelnes Dumpfile geschrieben.
Dieses ist daher komplett und kann alleine wieder eingelesen werden.
- 19 -
4.7.
Performancetest
Um zu ermitteln, wie gut das System skaliert, wurde beschlossen,
Performancetests durchzuführen. Die Idee war, über eine HTTP-Verbindung
Viveo anzusprechen und die Zeit zu messen, die benötigt wurde, um gewisse
Aktionen durchzuführen, konkret das Erstellen eines neuen BetGetter-Users. Es
sollte dann die Anzahl simultaner Verbindungen stetig erhöht werden, um
Aussagen über die maximale Anzahl gleichzeitiger Benutzer machen zu können.
Die Implementation des Perfomancetests befindet sich in der Klasse
betgetter.util.PerformanceTester.
Leider konnten nicht innert nützlicher Frist brauchbare Resultate erzielet werden.
Die benötigte Zeit zum Erstellen eines Users schwankt im Bereich zweier
Grössenordnungen, unabhängig von der Anzahl gleichzeitiger Anfragen, während
sich die Geschwindigkeit beim Benutzen des Systems via Browser meist recht
zügig anfühlt. Gemessen wird allerdings bloss die Zeit, die eine Methode des
Java-Packages java.net benötigt, um die Anfrage durchzuführen und eine
Antwort zu erhalten. Möglicherweise könnten mit der Verwendung eines anderen
HTTP-Clients realistischere und brauchbarere Resultate erzielt werden. Dies
auszuprobieren war leider aus Zeitgründen nicht mehr möglich.
- 20 -
5. Installation / Konfiguration
5.1.
Installation der Entwicklungs-Umgebung
Folgende Komponenten werden verwendet:
•
•
•
•
•
•
•
•
•
5.2.
Windows XP
Eclipse 2.1.1
http://www.eclipse.org/
Tomcat 4.1.27 (Achtung: Probleme mit Tomcat 4.1.29)
http://jakarta.apache.org/tomcat/
Sysdeo Tomcat-Plugin für Eclipse 2.2.0 (Sysdeo)
http://www.sysdeo.com/eclipse/tomcatPlugin.html
Sysdeo erweitert Eclipse um einige Praktische Features wie z.B. Tomcat
direkt aus Eclipse starten/debuggen etc.
Lomboz JSP-Plugin für Eclipse 2.1.1 (Lomboz)
http://www.objectlearn.com/
Lomboz ermöglicht JSP-Highlighting, Auto-Completion etc.
mail.jar
http://java.sun.com/products/javamail/
activation.jar
http://java.sun.com/products/javabeans/glasgow/jaf.html
jodd.jar
http://jodd.sourceforge.net/
inifile.jar
http://www.lebutch.org/inifiles.htm
Eclipse-Einstellungen
In Eclipse sind vier Projekte anzulegen:
•
•
•
•
dcg
clippee
betgetter
viveo
(Java-Project)
(Java-Project)
(Java-Project)
(Tomcat-Project)
Das Projekt viveo enthält ein Verzeichnis 'viveo', welches das Root-Verzeichnis
der Webapplikation ist. Die fünf *.jar-Files sind in das Verzeichnis viveo/WEBINF/lib zu kopieren. Der Kompilierungs-Output-Folder aller vier Projekte ist auf
viveo/WEB-INF/classes einzustellen (Dies kann erreicht werden, in dem in dcg,
clippee und betgetter je ein Verzeichnis erstellt wird, welches ein Link auf /WEBINF/classes darstellt). Unter Window > Preferences > Java > Compiler > 'Build
Path' Muss die Option 'Scrup output folders on full build' DEAKTIVIERT
werden.
5.3.
Konfiguration des Systems
Diverse Konfigurationen des BetGetter-Systems sind in der Datei config.ini
vorzunehmen (z.B. die IPs der verschiedene Peers). Tomcat muss mitgeteilt
werden, wo dieses File liegt. Das heisst, dass unter Windows > Preferences >
- 21 -
Tomcat > JVM_Einstellungen folgender Parameter zur JVM hinzugefügt werden
muss (der Pfad muss evtl. angepasst werden):
-DBETGETTER_CONFIG_FILE =
C:\eclipse\workspace\betgetter\config.ini
5.4.
Starten des Systems
Tomcat starten. Beim ersten Aufruf einer JSP-Seite, welche die Klasse
ApplicationBean einbindet, wird ein Clippee-Peer gestartet, der versucht, sich mit
andern Peers zu verbinden.
5.5.
Daten einlesen
Mittels der Methode ApplicationBean.readTestdata() können Match-Daten aus
einem in config.ini spezifizierten File eingelesen werden. Diese Testdaten sind im
comma-separated-values-Format anzugeben, siehe Beispiel-Files im Verzeichnis
betgetter/div
- 22 -
- 23 -
Anhang A: Interfacedefinition Frontend – Backend
Version 2.5
14.01.2004
User
List getMatches(String teamID, int timeConstraint, int
betConstraint, intMatchStateConstraint, String userID)
The first four parameters specify constraints for which the returned list will be
filtered.
int createAccount(String userID, String email, String password)
The returned integer is an errorcode that states success or a cause for the error.
int login(String userID, String password)
Returns an errorcode or ok if successed.
int placeBet (String userID, String matchID, int x12, int wager)
User getUser(String userID)
MatchBet1X2 getMatchBet1X2(String matchID, String userID)
Returns null if there is no Bet object for given match and user.
List getUserRanking()
Returns the whole ranking.
List getUserRanking(int count)
Returnes the top-count user ranking.
int getUserRank(String userID)
Returns the absolute rank of the user.
List getRecentBets(String userID, int count)
Returns a list of count matches that a user has placed bets for. The list is ordered
descending date-order.
List getRecentBetResults(String userID, int count)
Returns a list of count matches that a user has placed bets for and the results exist.
The list is ordered descending date order.
int createClique(String userID, String cliqueID)
List getCliqueRanking()
List getCliqueRanking(int count)
int getCliqueRank(String cliqueID)
List getUserRankingOfClique(String cliqueID)
Returns ranking for a clique (or null if clique does not exist).
int getUserRankInClique(String userID, String cliqueID)
Returns the rank of the user in a clique (or null if clique or user does not exist).
- 24 -
User getCliqueLeader(String cliqueID)
boolean isUserLeaderOfClique(String userID, String cliqueID)
List getCliquesForUser(int order, String userID)
Returns an ordered list of cliques the userID is member of.
int applyForClique(String userID, String cliqueID)
int invitePalForClique(String cliqueID, String email, String
senderUserID)
List getRequestingPalsForClique(int order, String cliqueID)
Returns list of cliques, [filter: order = ascending/descending userID].
int rejectPal(String cliqueID, String palID)
List getCliquesForLeader(int order, String userID)
Returns an ordered List of Cliques where userID is leader
Clique getClique(String cliqueID)
List getTeams()
Admin
int createMatch(String team1, String team2, Date date, String
stadium, String city, float rate1, float rateX, float rate2)
int setResult(String matchID, int score1, int score2)
Changes the result of a match.
int updateMatch(String matchID, String team1, String team2, Date
date, String stadium, String city, float rate1, float rateX,
float rate2)
Changes details about a non terminated match, returns TOO_LATE if match is
terminated or TEAM1_DOES_NOT_EXIST, TEAM2_DOES_NOT_EXIST,
INVALID_DATE.
int updateUser(String userID, String email, String password)
Changes the users email and password
List getUsers(int order, String firstLetter)
[filter: order = ORDER_ASCENDING resp. ORDER_DESCENDING
userID, firstLetter
(ignoring case) of userID]
int createTeam(String name)
List getTeams()
List getCliques(int order, String userID)
Returns list of users with either members or pals with userID, [filter: order =
ORDER_ASCENDING resp. ORDER_DESCENDING userID]
- 25 -
List getCliqueMembers(String cliqueID, int order)
Returns list of users, [filter: order = ORDER_ASCENDING resp. ORDER_DESCENDING
userID].
int addUserToClique(String cliqueID, String leaderID, String
palID)
int deleteUserFromClique(String userID, String cliqueID)
MatchBet1X2Quote getQuoteForMatch(String matchID)
Returns the quote for this match.
List getMatches(String teamID, int timeConstraint, int
betConstraint, int resultConstraint, int quoteConstraint, String
userID)
Returns a list of matches satisfying all filter constraints.
void readTestdata()
Reads some testdate from the file specified in config.ini.
int dumpState(String fileName)
Writes all clippee data to the specified file.
Constants
OK
USERID_EXISTS_ALREADY
USERID_DOESNT_EXIXT
WRONG_PASSWORD
NO_CONSTRAINT
PAST
FUTURE
TODAY
TOMORROW
NEXT_WEEK
YESTERDAY
ALREADY_BET
NOT_YET_BET
NOT_ENOUGH_MONEY_ON_YOUR_ACCOUNT
BET_NOT_POSSIBLE
TOO_LATE
TEAM1_DOES_NOT_EXIST
TEAM2_DOES_NOT_EXIST
INVALID_DATE
ORDER_ASCENDING
ORDER_DESCENDING
TEAM_ALREADY_EXISTS
MATCH_DOES_NOT_EXISTS
MATCH_HAS_NOT_STARTED_YET
CLIQUE_DOES_NOT_EXIST
CLIQUE_LEADER_REJECTS_USER
USER_IS_ALREADY_IN_CLIQUE
CLIQUE_NAME_EXISTS_ALREADY
and a few more, see ApplicationBean.java for details.
- 26 -
Anhang B: Datenmodell
- 27 -
Anhang C: DNS Round-Robin und Dynamic DNS
DNS Round-Robin soll die Belastung auf alle Server gleichmässig verteilen. Die
Statistik der Testwoche konnte dies auch bestätigen. Dadurch wird vermieden,
dass ein einzelner Rechner alle Anfragen zu bearbeiten hat und durch Überlastung
ausfällt. Fallen alle Server aus, funktioniert natürlich nichts mehr. Fällt nur ein
einzelner Rechner aus, so wird bei einer erneuten Abfrage (Refresh) eine IP eines
anderen Servers zurückgegeben. Dabei treten jedoch folgende Probleme auf:
•
Bei einem Webseitenaufruf wird in weiteren Nameservern bzw. der
Clientapplikation (hier Webbrowser) aus Effizienzgründen auf einen
Refresh des DNS-Eintrags verzichtet und stattdessen der bisherige Wert
aus einem Cache gelesen. Fällt nun ein Server aus, so wird bei einem
Refresh immer wieder der alte, aufgefallene Server angesprochen. Somit
ist die Applikation blockiert, obwohl noch lauffähige Server vorhanden
wären. No caching oder TTL niedrig/Null löst das Problem theoretisch,
aber nicht alle DNS-Clients (Browser, weitere DNS-Server) achten darauf.
•
DNS Round-Robin, auch mit no caching oder TTL niedrig/Null, erkennt
nicht, ob ein Server läuft oder nicht. Ein toter Server muss aber aus dem
DNS-Eintrag entfernt werden, um nicht weiterhin angesprochen zu
werden. Dies kann mittels Dynamic DNS geschehen. Zusätzlich wird eine
Überwachung der Server gebraucht, welche die Einträge von
ausgefallenen Servern aus dem DNS-Eintrag entfernt und solche von
(wieder) hinzukommenden Servern hinzufügt.
Die Frage stellt sich, wie schnell das System bei einem Ausfall eines Servers
reagieren muss. Des Weiteren muss die Überwachung ausfallsicher sein. Dies
könnte in Clippee und somit bei jedem Peer gemacht werden und zwar bei:
•
•
Anmelden eines Peers
Ausfall eines Peers
Die Überwachung führt beim Erkennen eines ausgefallenen Peers (Clippee ist in
der Lage, den Ausfall eines Peers zu detektieren) automatisch per Dynamic DNS
ein Update aus. Aufgrund der erhaltenen Message entfernt der zuständige DNSServer den ausgefallenen Server aus dem DNS-Round-Robin-Eintrag. Kommt ein
neuer Peer hinzu, wird er auf dieselbe Weise in den DNS-Eintrag geschrieben.
Als Protokoll ist BIND vorzuschlagen.
- 28 -
Bibliographie
[Clippee]
Albrecht, K.; Arnold, R.; Wattenhofer, R., "Clippee: A LargeScale Client/Peer System", Department of Computer Science,
ETH Zürich, 2003,
http://www.distcomp.ethz.ch/publications/srdsws03.pdf
[Tomcat]
The Apache Jakarta Project,
http://jakarta.apache.org/tomcat/
[W3C]
W3C, World Wide Web Consortium,
http://www.w3.org/
[Lotterie]
Das Schweizerische Lotteriegesetz,
http://www.admin.ch/ch/d/sr/935_51/a33.html
[NHL]
The National Hockey League,
http://www.nhl.com
[eishockey.com] Das NHL Eishockey Magazin im Web,
http://www.eishockey.com
[Java]
http://java.sun.com/j2se/1.4.2/docs/api/
[Javadoc]
http://java.sun.com/j2se/javadoc/
[CVS]
Concurrent Versioning System,
http://www.cvshome.org/
[Eclipse]
The Eclipse Foundation,
http://www.eclipse.org/
[IDEA]
Intelli J IDEA,
http://www.intellij.com/idea/
[BIND]
Berkeley Internet Name Domain,
http://www.isc.org/index.pl?/sw/bind/
Alle Internetseiten wurden am 26. Februar 2004 zuletzt besucht.
- 29 -