[delphi] Synchronisatie via sockets

[jopiek]

Ik heb een leuk proggie geschreven zodat DigiStorm, myself en onze andere twee huisgenoten een aardige actie op ons aankomende huisfeest kunnen houden: vanaf meerdere pc's en dus meerdere kamers kunnen we nu mp3's afspelen

Maar, ik doe het nu op de gok, weet iemand hoe ik op een adequatere manier kan zorgen dat alle proggies exact tegelijk mp3player.start uitvoeren???
Ik gebruik sockets om het zaakje aan elkaar te hangen op een manier zoals de delphi chat demo... Een van de proggies is server en de rest is automatisch client...

[TheOneLLama]

Op zondag 10 februari 2002 21:29 schreef jopiek het volgende:
Ik heb een leuk proggie geschreven zodat DigiStorm, myself en onze andere twee huisgenoten een aardige actie op ons aankomende huisfeest kunnen houden: vanaf meerdere pc's en dus meerdere kamers kunnen we nu mp3's afspelen

Maar, ik doe het nu op de gok, weet iemand hoe ik op een adequatere manier kan zorgen dat alle proggies exact tegelijk mp3player.start uitvoeren???
Ik gebruik sockets om het zaakje aan elkaar te hangen op een manier zoals de delphi chat demo... Een van de proggies is server en de rest is automatisch client...

Als dit op een LAN is is de pingtijd waarschijnlijk zo laag dat dit niet van invloed is.. ik zou me meer zorgen maken om die "mp3player", die doet vast aan prebuffering ofzo waardoor het net allemaal wat minder synchroon loopt. Misschien eerst heel even aan doen en meteen op pauze laten zeten als dat mogelijk is? en dan op het tweede signaal weer aan..

Verder ben ik niet echt bekent met Delphi-sockets maar ik neem aan dat ze geen rare buffering ed. doen. Als dit wel zo is kan je het beste via windows API van winsock gebruik maken..

[jopiek]

volgens mij kun je juist beter geen gebruik maken van de directe API a.d.h.v. berichten die ik gelezen heb, maar dit lost het probleem nog niet op.

Ik wil gewoon exact weten op welk moment iets gebeuren moet. De TMediaplayer die ik gebruik is volgens mij niet al te intelligent en doet ook nauwelijks aan buffering. En daarnaast is play -> pause -> play een lelijke oplossing.

Als ik echter wil meten per applicatie wat bijv. de vertraging is na versturen van een commando en het afspelen van de mp3 (wat volgens mij met name veroorzaakt wordt door het verschil in MHz's van de CPU en bussnelheid e.d.) moet ik toch wel een gemeenschappelijke timing hebben...

Volgens mij is dit het beruchte twee leger probleem

[mjax]

Is het niet gemakkelijker om een interne ShoutCast server o.i.d. op te zetten, waar de andere clients op "inloggen"?

[jopiek]

Op maandag 11 februari 2002 08:38 schreef MarcKonings het volgende:
Is het niet gemakkelijker om een interne ShoutCast server o.i.d. op te zetten, waar de andere clients op "inloggen"?

zou dat zorgen dat ze allemaal op het zelfde moment spelen???

[Verwijderd]

ja

[jopiek]

en hoe koppel ik dat SHOUTcast gedoetje aan de delphi clients???

ik wil een aantal acties uitvoeren waarbij ik sowieso m'n eigen proggie nodig heb...

[TheOneLLama]

Op maandag 11 februari 2002 10:14 schreef Zoepnek het volgende:
ja

Nee.. SHOUTCAST doet zeker aan buffering ed. waardoor je nooit op precies hetzelfde moment zult starten..

[TheOneLLama]

Op maandag 11 februari 2002 08:09 schreef jopiek het volgende:

Ik wil gewoon exact weten op welk moment iets gebeuren moet. De TMediaplayer die ik gebruik is volgens mij niet al te intelligent en doet ook nauwelijks aan buffering. En daarnaast is play -> pause -> play een lelijke oplossing.

Als ik echter wil meten per applicatie wat bijv. de vertraging is na versturen van een commando en het afspelen van de mp3 (wat volgens mij met name veroorzaakt wordt door het verschil in MHz's van de CPU en bussnelheid e.d.) moet ik toch wel een gemeenschappelijke timing hebben...

Tja je netwerklag is extreem laag op een LAN (ver onder de 1 ms).. als jij zegt dat gebruik maken van een Delphi component die latency niet verhoogd (ik heb geen ervaring met die dingen dus..) dan zal het aan netwerklag niet liggen, maar wel aan hoe lang het duurt om dat MP3tje op te starten.

Ik weet ook wel dat play-pause-play een lelijke oplossing is, maar je zult toch een manier moeten vinden waardoor je MP3tje echt klaar staat om te beginnen, dus overal zo weinig mogelijk buffering ed. (misschien maar niet van TMediaplayer gebruik maken dan als die dat niet kan..)

Als je ondanks alles toch geloofd dat het vooral aan ligt wat er voor .start gebeurt en niet erna:

- meet de roundtrip en bereken aan de hand hiervan uit waneer je welke client het commando om te starten moet geven (dit maakt je programmatje vooral ook geschikt voor gebruik over een inet connectie en niet alleen een LAN)
- zorg dat je clients geen onnodige parsing van data hoeven te doen, dus dat je in je protocol ervoor zorgt dat ze op een gegeven moment alleen nog maar hoeven te wachten tot ze data ontvangen en dan gelijk naar .start springen (dus niet eerst kijken wat voor data het is of wat dan ook.. zodra je het event krijgt gelijk .start
- zorg dat je TCP/IP verbindingen geen gebruik maken van Nagle's algorithm. In JAVA bv. doe je dit met setTcpNoDelay. Of een Delphi component dit kan weet ik niet. Ook iedere andere vorm van buffering moet je voorkomen!

Succes

[jopiek]

Op maandag 11 februari 2002 14:02 schreef TheOneLLama het volgende:

[..]

Tja je netwerklag is extreem laag op een LAN (ver onder de 1 ms).. als jij zegt dat gebruik maken van een Delphi component die latency niet verhoogd (ik heb geen ervaring met die dingen dus..) dan zal het aan netwerklag niet liggen, maar wel aan hoe lang het duurt om dat MP3tje op te starten.

Ik weet ook wel dat play-pause-play een lelijke oplossing is, maar je zult toch een manier moeten vinden waardoor je MP3tje echt klaar staat om te beginnen, dus overal zo weinig mogelijk buffering ed. (misschien maar niet van TMediaplayer gebruik maken dan als die dat niet kan..)

Als je ondanks alles toch geloofd dat het vooral aan ligt wat er voor .start gebeurt en niet erna:

- meet de roundtrip en bereken aan de hand hiervan uit waneer je welke client het commando om te starten moet geven (dit maakt je programmatje vooral ook geschikt voor gebruik over een inet connectie en niet alleen een LAN)
- zorg dat je clients geen onnodige parsing van data hoeven te doen, dus dat je in je protocol ervoor zorgt dat ze op een gegeven moment alleen nog maar hoeven te wachten tot ze data ontvangen en dan gelijk naar .start springen (dus niet eerst kijken wat voor data het is of wat dan ook.. zodra je het event krijgt gelijk .start
- zorg dat je TCP/IP verbindingen geen gebruik maken van Nagle's algorithm. In JAVA bv. doe je dit met setTcpNoDelay. Of een Delphi component dit kan weet ik niet. Ook iedere andere vorm van buffering moet je voorkomen!

Succes

maar het twee-leger probleem is dus in dit geval op te lossen door een aantal roundtrips te timen, alleen weet ik niet exact hoe ik in nanoseconden moet gaan tellen in Delphi maar dat is uit te zoeken...

verder werkt de applicatie nu er aardig en in ons studentenhuis staan de pc's zo ver uit elkaar dat er sowieso vertraging is door de snelheid van het geluid en de milliseconde verschil dus niet echt opvalt...

Overmorgen zal ik 't daar ff zien te testen...