[PHP] Verschil in tijd uitrekenen tussen Client en Server

[vorlox]

He,

Ik ben bezig met een sync programmatje. Nu loopt het syncen in principe prima echter wanneer er een verschil in tijd (seconden) zit (Dus niet echt een andere timezone) dan stuur ik nu de client tijd mee naar de server ..en op de server reken ik het verschil uit.

Maar er zit natuurlijk ook tijd in de request van de client naar de server...en nu probeer ik uit te zoeken hoe ik die request tijd zou kunnen meten.

Wat ik nu probeer is boven aan in het script de huidige servertijd op te slaan in een variabele alleen dan zit je natuurlijk al op de server..en ik heb ook de tijd van de client... Maar ik wil zegmaar de response tijd hebben.

Begrijpt iemand wat ik bedoel? Ik kan het misschien niet goed uitleggen daarom ik niks erover vinden kan.

Uitleg
Ok even klein stukje verdere uitleg
Ik heb op de server een mysql tabelletje met de volgende velden
id (int)
subject (text)
content (text)
modified (datetime)

Op de client sla ik de laatste sync tijd op.
Bij de volgende sync vraag ik dus eigenlijk aan de server

code:

SELECT * FROM agenda WHERE modified > '{lastSyncDate}'

Als je dus snel achter elkaar sync krijg je soms problemen.

[ Voor 21% gewijzigd door vorlox op 19-06-2008 14:21 ]

[RobIII]

Waarom het wiel opnieuw uitvinden NTP is het steekwoord Kwestie van even googlen i.c.m. het php steekwoord en er moet zat te vinden zijn

[ Voor 70% gewijzigd door RobIII op 19-06-2008 12:57 ]

[vorlox]

Hmm uh ik draai op zowel client als server NTP echter linux wil wel eens een paar stapjes missen en zo +/- 20/30 seconden verschillen...dat wordt na een paar seconden wel weer rechtgezet door linux echter als je precies dan synct heb ik dus bovenstaand probleem

[Janoz]

Bij mij thuis laat ik de server syncen met een internet server en alle clients vervolgens met mijn eigen server. Ik kan me niet voorstellen dat dat op een gegeven moment 30sec out of sync loopt. Mocht dat gebeuren dan zou ik toch wat vaker gaan syncen.

[_js_]

Gewoon een ping doen, dat geeft de roundtrip tijd aan (dus van client naar server naar client).

[RobIII]

Janoz schreef op donderdag 19 juni 2008 @ 13:27:
Bij mij thuis laat ik de server syncen met een internet server en alle clients vervolgens met mijn eigen server. Ik kan me niet voorstellen dat dat op een gegeven moment 30sec out of sync loopt. Mocht dat gebeuren dan zou ik toch wat vaker gaan syncen.

Dat is ook precies hoe het hele NTP gebeuren bedoeld is met al z'n strata etc. Ik kan me voorstellen (inderdaad) dat je een seconde of wat afwijkt, maar 20/30 seconden is achterlijk veel. In dat geval moet je eens gaan kijken naar een nieuw onboard clockje (VM's hebben er nog wel eens last van overigens, maar dat is vaak een kwestie van een of andere 'sync time with host' optie aanzetten ofzo).

_js_ schreef op donderdag 19 juni 2008 @ 13:30:
Gewoon een ping doen, dat geeft de roundtrip tijd aan (dus van client naar server naar client).

Da's leuk, maar geeft enkel de indicatie van hoe lang een pakketje heen-en-weer onderweg is en heeft niets van doen met de responsetijd van je webserver etc. Maar dat neemt niet weg dat al dit soort oplossingen gewoon symptoombestrijding zijn. Je moet gewoon zorgen dat je tijd (betrouwbaar) gelijk is en blijft.

[ Voor 25% gewijzigd door RobIII op 19-06-2008 13:32 ]

[vorlox]

Ik krijg in mijn log continue
time reset -1.221025 s
time reset +0.168689 s

Dus de ene keer plus en de andere keer -
Het is zo te zien veel minder als 20 / 30 seconden eerder 2 / 3 seconden afrondings foutje in mijn php script

Echter ik zit dus met een paar sec verschil...met syncen maakt dat aardig uit denk ik.

Overigen het draait idd op Vm-server ...echter ik heb alle mogelijke dingen gedaan om VM en timing goed te laten lopen
Dus o.a in vm.conf de CPUHz e.d ingesteld en natuurlijk draai ik vm-tools.

enz hij doet het nu om de 10 minuten lijkt het op...is dat te lang

[ Voor 20% gewijzigd door vorlox op 19-06-2008 13:36 ]

[RobIII]

vorlox schreef op donderdag 19 juni 2008 @ 13:34:
is dat te lang

Dat is maar net hoe belangrijk het voor je is; mag je max. een verschil van 0.0001 seconde hebben (ik roep maar wat) dan moet je inderdaad misschien vaker syncen. Maar ben je niet bezig met iets heel ranzigs als je op deze manier een 'sync' van het een of ander hebt waarbij het zo belangrijk is dat de tijd gelijk loopt? Kun je geen markers plaatsen a-la 'tot hier is de laatste keer gesynct' ofzo? Ik ruik namelijk iets engs ... Als je proces al afhankelijk is van een paar milliseconden tijdsverschil tussen client/server dan moet je eens gaan kijken of dat niet anders op te lossen is dan 'meten' wat het verschil is; anders komt het allemaal aan op de betrouwbaarheid van je 'meting' (die overigens van request tot request flink kan fluctueren) en ik kan je vast verklappen dat je dat nooit helemaal goed gaat krijgen.

V V En wat hij hieronder zegt dus V V

[ Voor 28% gewijzigd door RobIII op 19-06-2008 13:39 ]

[Janoz]

Ik weet niet hoe je je syncen nu geïmplementeerd hebt, maar het lijkt me handiger wanneer je een marge inbouwt, of je algoritme onafhankelijk van looptijd maakt. Echter zonder meer informatie over je daadwerkelijke implementatie valt daar verder weinig over te zeggen.

edit: met de neus van RobIII dus..

[ Voor 6% gewijzigd door Janoz op 19-06-2008 13:38 ]

[Voutloos]

Janoz schreef op donderdag 19 juni 2008 @ 13:37:
of je algoritme onafhankelijk van looptijd maakt

Of gewoon een logische klok.

[vorlox]

Even topic post uitgebreid met meer info

[Voutloos]

vorlox schreef op donderdag 19 juni 2008 @ 12:28:
Op de client sla ik de laatste sync tijd op.

De client hoeft enkel de hoogste waarde van modified te onthouden (en bij auto_inc kan id ook werken). Als dat verder gewoon monotoon oplopend is boeit het niet dat het een tijd is, of dat er een tijdsverschil zit tussen client en server.

[ Voor 4% gewijzigd door Voutloos op 19-06-2008 14:24 ]

[vorlox]

De client hoeft enkel de hoogste waarde van modified te onthouden (en bij auto_inc kan id ook werken). Als dat verder gewoon monotoon oplopend is boeit het niet dat het een tijd is, of dat er een tijdsverschil zit tussen client en server.

Auto incremental id kan volgens mij niet werken want dan krijg je niet de wijzigingen binnen maar alleen de nieuwe.
Verder dacht ik dat ik de hele datum/tijd combinatie van de sync op de client moet opslaan, want als iemand 2 dagen niet synct is volgens mij de laatste waarde Seconden niet genoeg.
Ook zit ik met het feit dat outlook bij het aanmaken zelf een lastmodified aanmaakt. En die is readonly.

[Voutloos]

vorlox schreef op donderdag 19 juni 2008 @ 14:32:
Verder dacht ik dat ik de hele datum/tijd combinatie van de sync op de client moet opslaan, want als iemand 2 dagen niet synct is volgens mij de laatste waarde Seconden niet genoeg.

Ik heb het niet enkel over seconden?

Ook zit ik met het feit dat outlook bij het aanmaken zelf een lastmodified aanmaakt. En die is readonly.

Ik weet niet wat Outlook allemaal doet, maar tot deze post kon niemand ook weten dat het om Outlook ging.

[ripexx]

Ik blijf het een vaag verhaal vinden... wat probeer je nu exact te doen?

Outlook --> plugin? --> phpcode --> MySQL database

Zo ja is dit je eigen plugin of iets anders? Verder lees ik dat outlook zelf een last modified heeft, kan je die waarde dan niet gebruiken? Heb je deze waarde nodig of kan je die opslaan in een sessie en die gebruiken voor je verschil berekening in php? Wellicht dat er nog andere oplossingen zijn als je iets meer info over de opzet kan geven.

[Gomez12]

Je moet niet naar het syncen kijken, want zoals ik het lees is het een 2-way sync tussen 2 verschillende systemen dus theoretisch kan 1 item 100% dezelfde last modified tijd hebben op alle 2 de systemen.

Ik zou het als volgt doen :
Gewoon eerst zorgen dat je ntp goed loopt ( dus ntp opzetten tussen client en server, niet alletwee met inet), dan kijk je over een periode van 1 week wat de maximale drift is.
Daarna stel je een overlooptijd / conflicttijd in die 2x de maximale drift is.
Voordat je gaat syncen (en als er al x tijd niet meer gesynct is) dan doe je eerst een ntp-update.
Dan sync je. Alle items die in de overlooptijd / conflicttijd liggen daar val je een gebruiker mee lastig, laat hem maar kiezen.
Als je ntp goed staat ingesteld dan komen er in principe geen / heel weinig items binnen je overlooptijd. Dus dan wordt het meer een theoretisch probleem...

[RobIII]

Gomez12 schreef op donderdag 19 juni 2008 @ 20:18:
Ik zou het als volgt doen :
...

O...M...G...
Is dat niet een beetje overkill voor een simpele 2-way sync? Er moeten toch (en zijn toch) legio andere mogelijkheden om dit soort zaken aan te pakken?
Het hele NTP verhaal ben ik begonnen toen de TS nog maar half compleet was en er een heel andere idee bij mij ontstond van wat vorlox probeerde te bereiken dan nu blijkt. Maar er zijn zat andere manieren die niet eens afhankelijk hoeven te zijn van een datum/tijd/klok.

[vorlox]

He Robb, uh interessant....kun je misschien een klein beetje uit de doeken doen wat dan een andere manier kan zijn?

Ik heb zelf al zitten denken aan het hashen van de afspraken in een steuntabelletje en dan de hashes te vergelijken, echter dan kan het natuurlijk wel zijn dat je de conflicten via een tussenscherm door de gebruiker zelf laat kiezen welke leading moet zijn

[RobIII]

vorlox schreef op vrijdag 20 juni 2008 @ 09:47:
echter dan kan het natuurlijk wel zijn dat je de conflicten via een tussenscherm door de gebruiker zelf laat kiezen welke leading moet zijn

Dat blijf je, hoe dan ook, toch houden. Daar ontkom je gewoon niet aan.
Ik ken de exacte beschikbare data aan beide zijden niet dus ik kan weinig zinnige uitspraken over de synchronisatie doen maar een dusdanig omslachtig systeem met NTP (en geforceerd updaten etc.) voor het simpel synchroniseren van wat afspraken is volgens mij een schoolvoorbeeld van een "over-engineered" oplossing voor een basic probleem.

@TS: Ben je het wiel niet opnieuw aan het uitvinden? Al eens gekeken naar (of gespiekt in) oplossingen als SyncML / OpenSync e.d.?

[ Voor 22% gewijzigd door RobIII op 20-06-2008 10:22 ]

[Gomez12]

@RobIII : NTP is opzich helemaal niet nodig hoor, alleen 2 klokken die enigszins gelijklopen.

Alleen dat heeft de TS nu al en dat is niet voldoende voor TS, dan moet je gewoon een manier hebben om de klokken gelijk te laten lopen en die manier is gewoon NTP...

En als TS zich zorgen maakt om respons tijd van de server dan krijg je wel een paar uitdagingen...

[Voutloos]

Gomez12 schreef op vrijdag 20 juni 2008 @ 10:46:
@RobIII : NTP is opzich helemaal niet nodig hoor, alleen 2 klokken die enigszins gelijklopen.

De klokken boeien niet. Het gaat puur om het punt tot waar gesynct is en dat kan prima door de max modified waarde te onthouden of dmv een logische klok. Klokken in een distributed system met ultieme precisie synchroniseren is juist 1 vd bekendste netwerk moeiijkheden, welke je je, ook al zijn er wat oplossingen voor, niet voor de lol erbij moet slepen.

[Erkens]

vorlox schreef op donderdag 19 juni 2008 @ 14:32:
[...]


Auto incremental id kan volgens mij niet werken want dan krijg je niet de wijzigingen binnen maar alleen de nieuwe.
Verder dacht ik dat ik de hele datum/tijd combinatie van de sync op de client moet opslaan, want als iemand 2 dagen niet synct is volgens mij de laatste waarde Seconden niet genoeg.
Ook zit ik met het feit dat outlook bij het aanmaken zelf een lastmodified aanmaakt. En die is readonly.

Begrijp ik het goed dat je Outlook wilt syncen met iets anders? Kijk dan eens naar de Incremental Change Synchronization implementatie van MAPI.

[vorlox]

Uh ja uiteindelijk wil ik idd. dmv een outlook addin de data syncen..
Wat ik dus niet gevonden had waren o,a

Kijk dan eens naar de Incremental Change Synchronization implementatie van MAPI.
en
SyncML / OpenSync e.d.?

daar ga ik eerst even naar kijken want om idd opnieuw het wiel uit te vinden is onzin
Snap niet dat ik die OpenSync niet ben tegen gekomen in mijn zoektoch.

Ik meld me weer terug

[Verwijderd]

vorlox schreef op donderdag 19 juni 2008 @ 12:28:
stuur ik nu de client tijd mee naar de server ..en op de server reken ik het verschil uit.

Dan laat je ook de server de tijd (-verschil) weer meesturen?