[java] spelklok in applets

[Verwijderd]

Voor een online damapplet heb ik een spelklok nodig.
De applets werken via http request naar php pagina's die mysql queries uitvoeren.
Dit werkt allemaal goed.

Mijn vraag is of iemand een idee heeft omtrend het opzetten van een spelklok. Wanneer ik aan beide kanten gewoon een thread laat lopen, lopen ze na een aantal zetten niet meer synschroon.

Wat is de beste opties / zijn de opties?

Haike

[Pooh]

Waarom zou je 2 threads gebruiken? Gewoon 1 thread die ofwel klok 1, ofwel klok 2 laat lopen is toch genoeg?

edit: Of moet 't perse clientside? Lijkt me een stuk handiger om 't serverside te doen iig.

[ Voor 31% gewijzigd door Pooh op 01-03-2006 16:14 ]

[Nick_S]

Werk met Events

Events
Events allow simpletons to communicate transient messages to each other. The pool acts as a global event channel and dispatcher, connecting event-handling simpletons to event-generating simpletons. An event-handling simpleton expresses interest in a given event by subscribing to the pool with an appropriate event constraint. Event constraints are the programmatic equivalent of a semi-permeable membrane, allowing desired events to trickle down to a simpleton and denying access to all other events. Following the running example of a game clock tick, any simpleton that wishes to be synchronized with the game clock tick simpleton would subscribe to the pool with an event constraint that declares, "I am interested in any and all game tick events that pass through the pool."

Events encapsulate information by holding references to relevant data and through their specific subtype (some events are merely marker types without any additional fields).

Je hebt hierin dan waarschijnlijk drie partijen, Client A, Client B, Server. (Eventuele andere partijen zouden bijvoorbeeld een GameLogger of Lurker kunnen zijn)

Server verstuurt TickEvents naar de pool. Bij het ontvangen van een TickEvent zullen Client A en Client B de klok op de goeie tijd zetten (Let op, in het event staat dus de goeie tijd, mocht er dan een keer een event niet doorkomen of een Lurker komt later binnen, zal deze dus de goede tijd blijven/gaan weergeven)

Clients versturen bijvoorbeeld ChatEvents of TurnEvents, welke door de Server/Clients weer afgevangen en verwerkt kunnen worden.

Andere Events die je nog zou kunnen gebruiken: GameOverEvent, GameStartedEvent.

[Verwijderd]

het kan niet serverside, dan zou de structuur:

applet - server - applet
moeten zijn.

Het zijn nu 2 applets die met elkaar communiceren via php pagina's. Daarom kan ik niet 1 centrale thread laten draaien.

[JKVA]

Kun je niet iets met sockets of RMI doen?

edit:
Ps. Op applets rusten wel veel strengere beveiligingseisen, dus misschien roep ik iets onzinnigs.

[ Voor 59% gewijzigd door JKVA op 01-03-2006 19:22 ]

[Verwijderd]

JKVA schreef op woensdag 01 maart 2006 @ 19:19:
Kun je niet iets met sockets of RMI doen?

edit:
Ps. Op applets rusten wel veel strengere beveiligingseisen, dus misschien roep ik iets onzinnigs.

Gewoon een certificaat dinges aan maken en je bent voorbij de meeste beveiliging dingen..

[Robtimus]

Verder mogen applets veel wat betreft communicatie met de server waar de applet vandaan komt.

[JKVA]

Ik zou zeggen, ga voor sockets. Dat is als je net begint gemakkelijker dan RMI. Gewoon Strings over een lijntje sturen.

Met betrekking tot de klok. Laat beide applets een system.nanotime o.i.d. doen, naar elkaar versturen en de gene met de laagste tijd (of hoogste) is de host die de klok bijhoudt en tijdevents naar de andere stuurt.

Je kunt ook de gebruiker laten kiezen of hij host of client is, maar die met die tijd lijkt me makkelijker.

[Verwijderd]

bij een signed applet zou ik inderdaad sockets kunnen doen, alleen ervaringen hiermee leren dat dit niet altijd lekker werkt, binnen netwerken en firewalls. RMI heb ik geen verstand van maar het lijkt me dat dit hetzelfde probleem oplevert.

Verder is het ook zo dat er toeschouwers aanwezig (kunnen) zijn bij een partij, dit maakt een socketstructuur ook wat lastiger.

Kan iemand met zekerheid zeggen of je met een signed applet geen last hebt van firewalls, natting en socketprogrammeren in het algemeen?

[JKVA]

Ehm, ik heb ooit voor school een spel gemaakt in Java (RTS voor de geinteresseerden). Dat was geen applet, maar een applicatie. En zelfs toen moesten we een port forwarden naar de luisterende socket.

[Verwijderd]

een applicatie heeft die restricties van een applet niet. Een applicatie zou veel makkelijker zijn qua implementatie maar is hier geen optie.

[JKVA]

Ik wilde er vooral mee aangeven dat het met een applicatie al lastig genoeg was en een Applet waarschijnlijk dus nog lastiger.