Client-Server KeepAlive of Server-Client KeepAlive

[Verwijderd]

Ik maak samen met een andere jongen uit mijn klas een project voor school waar we een applicatie die toezicht kan houden op een openleercentrum, opnieuw moeten schrijven.

De structuur is als volgt.
Bepaalde mensen die toezicht houden op een open leercentrum maken gebruik van een programma waar ze onder anderen de mogelijkheid hebben om mee te kijken bij computers en ze uit te loggen.
Er draait 1 server die in feite alle communicatie regelt, deze ontvangt commands vanaf de beheerapplicaties en verstuurd ze vervolgens naar de computer(s) waar het naartoe moet. Deze server moet ook in de gaten houden welke computers nog zijn ingelogd. In de huidige situatie wordt dit gedaan door de server, deze stuurt om de zoveel seconden een ping naar elke client.

Nu is onze vraag of het misschien slimmer is om alle clients een 'ping' te laten sturen om aan te geven dat ze nog zijn ingelogd, in plaats van de server.

[MicroWhale]

Je kunt via een broadcast van de server een reactie van de clients opwekken om te laten weten dat ze er zijn.

[Verwijderd]

Logos schreef op dinsdag 07 maart 2006 @ 10:50:
Je kunt via een broadcast van de server een reactie van de clients opwekken om te laten weten dat ze er zijn.

Het gaat eigenlijk niet om een normale ping, het gaat erom dat er wordt gekeken of het programma wat op de reactie hoort te reageren, nog wel draait. Dus het gaat om een eigen pakketje wat om de zoveel tijd verstuurd wordt.

[H!GHGuY]

ik ga je probleem nog moeilijker maken...
wat is de ECHTE server en wat is de ECHTE client...

- de server(serverpc) vraagt gegevens op aan de clients(clientpc) en zendt deze door naar een andere client(clientpc)
OF
- de server(clientpc) wacht op de client(serverpc) om gegevens op te vragen zodat deze client(serverpc) ze kan doorzenden naar een andere client(clientpc)

vanuit puur software-standpunt zou ik zeggen: de client zendt een keepalive naar de server aangezien hij misschien nog diensten wil van de server en de overhead voor een nieuwe verbinding niet wil hebben.

Om het probleem dan weer simpeler te maken:
jouw client-software(niet beheer) is eigenlijk serversoftware.
jouw server-software is eigenlijk een relay.
jouw client-software(beheer) is eigenlijk clientsoftware.

de keuze is terug aan jou

[Verwijderd]

Wij zijn ondertussen al tegen een punt gelopen waarvoor inderdaad de keepalive vanaf de client moet worden geregeld dus we zijn er eigenlijk al uit

[MicroWhale]

Verwijderd schreef op dinsdag 07 maart 2006 @ 10:59:
[...]


Het gaat eigenlijk niet om een normale ping, het gaat erom dat er wordt gekeken of het programma wat op de reactie hoort te reageren, nog wel draait. Dus het gaat om een eigen pakketje wat om de zoveel tijd verstuurd wordt.

Een broadcast is in dit geval ook een eigen pakketje en dat wat de Client verstuurd, kun je bij het ontvangen van de broadcast op de client ook zelf bepalen.
Een ping vind ik niet echt geschikt om het nog beschikbaar zijn van een client te bepalen. Wij doen het hier ongeveer als volgt:

- server broadcast roept (om de x seconden): "welke clients zijn beschikbaar?"
- clients (die de broadcast horen): "<computernaam> ikke!"

Zo weet de server welke services nog draaien.

De client draait een (voor de gebruiker onzichtbare) windows-service application met geimplementeerde soap-calls.
De server kan dus rechtstreeks op een client bepaalde procedures aanroepen.

[ Voor 4% gewijzigd door MicroWhale op 07-03-2006 13:52 ]

[Question Mark]

Logos schreef op dinsdag 07 maart 2006 @ 13:52:
[...]
Een broadcast is in dit geval ook een eigen pakketje en dat wat de Client verstuurd, kun je bij het ontvangen van de broadcast op de client ook zelf bepalen.
Een ping vind ik niet echt geschikt om het nog beschikbaar zijn van een client te bepalen. .

Nadeel van een broadcast is wel, dat zodra clients en server gescheiden zijn door een router (bv. bij verschillende subnets), de applicatie meteen niet meer werkt. Broadcast gaat nl. niet over Layer 3 heen..

[MicroWhale]

Question Mark schreef op dinsdag 07 maart 2006 @ 13:55:
[...]

Nadeel van een broadcast is wel, dat zodra clients en server gescheiden zijn door een router (bv. bij verschillende subnets), de applicatie meteen niet meer werkt. Broadcast gaat nl. niet over Layer 3 heen..

dat klopt ja, en dat is gelukkig voor ons juist geen beperking maar een hele aangename bijkomstigheid. Zo hebben we hardwarematige controle over wat bij wat hoort en bovendien storen we de rest van het bedrijf niet met onze bezigheden.

[whoami]

Je kan toch gewoon een client laten 'subscriben' op de server als hij inlogged, en laten unsubscriben als hij weer uitlogt ?

[MicroWhale]

whoami schreef op dinsdag 07 maart 2006 @ 19:42:
Je kan toch gewoon een client laten 'subscriben' op de server als hij inlogged, en laten unsubscriben als hij weer uitlogt ?

en wat dan als de client opnieuw opstart zonder unsubscribe?

[whoami]

Dat kan je toch wel opvangen ?

[Verwijderd]

hoe dan ?

[Verwijderd]

whoami schreef op dinsdag 07 maart 2006 @ 20:03:
Dat kan je toch wel opvangen ?

Hoe is dat op te vangen dan

[ Voor 10% gewijzigd door Verwijderd op 07-03-2006 20:44 ]

[whoami]

Tja, dat hangt toch af van de taal / omgeving die je dan gebruikt. Als je applicatie afgesloten wordt -wat gebeurd als de client opnieuw opstart-, dan kan je toch unsubscriben.

[Verwijderd]

whoami schreef op dinsdag 07 maart 2006 @ 20:50:
Tja, dat hangt toch af van de taal / omgeving die je dan gebruikt. Als je applicatie afgesloten wordt -wat gebeurd als de client opnieuw opstart-, dan kan je toch unsubscriben.

Als een computer gewoon roekeloos uit wordt gedrukt wordt kan het programma niet meer unsubscriben, ongeacht welke taal.

[whoami]

Dan kan je er alsnog een veiligheid in bouwen dat de server een client unsubscribed als hij na xxx minuten geen activiteit meer ontvangen heeft van een bepaalde client.

[Verwijderd]

maar dan zal de client of server sowieso om de zoveel minuten/seconden iets moeten sturen, en daar gaat de vraag juist over

[whoami]

Of, als je ziet dat eenzelfde client voor de 2de keer connect, kan je de eerste uitloggen.

[Verwijderd]

Dat kan, dit zou echter wel betekenen dat in de tussentijd, de computer nog steeds staat genoteerd als ingelogd, wat niet de bedoeling is

[Kayshin]

whoami schreef op dinsdag 07 maart 2006 @ 21:39:
Of, als je ziet dat eenzelfde client voor de 2de keer connect, kan je de eerste uitloggen.

Stel dat je wil weten of er bepaalde clients zijn ingelogd, maar deze is uitgedrukt en staat uit, krijg je zo niet het probleem dat hij dan nog ingelogd staat?

Het komt er dus op neer dat je altijd nog signalen van de clients moet opvangen, of je het nu doet met een broadcast, om de zoveel cpu-cycles, om de 5 minuten, dit maakt dus niet uit.

[MicroWhale]

Verwijderd schreef op dinsdag 07 maart 2006 @ 21:50:
Dat kan, dit zou echter wel betekenen dat in de tussentijd, de computer nog steeds staat genoteerd als ingelogd, wat niet de bedoeling is

juist...

tis wel grappig om dit te lezen: iedereen komt dezelfde "problemen" tegen bij het genereren van een client-server opstelling met keepalive opties.

[MicroWhale]

Kayshin schreef op woensdag 08 maart 2006 @ 00:45:
[...]

Stel dat je wil weten of er bepaalde clients zijn ingelogd, maar deze is uitgedrukt en staat uit, krijg je zo niet het probleem dat hij dan nog ingelogd staat?

Het komt er dus op neer dat je altijd nog signalen van de clients moet opvangen, of je het nu doet met een broadcast, om de zoveel cpu-cycles, om de 5 minuten, dit maakt dus niet uit.

dat ligt eraan hoe kritisch datgene is wat op de client draait.

er zijn een aantal controle momenten. Hier controleren we:
- om de minuut alle tig machines (verkrijg lijst van machines met client via soort van broadcast),
- om de 5 seconden 1 van de machines uit boven verkregen lijst in een round-robin,

het zijn twee keep-alive mechanismen die elkaar aanvullen. Deze opzet is gekozen om niet al teveel netwerkverkeer te genereren en om er toch zeker van te zijn dat alle machines nog draaien.

mocht de aangesproken machine niet meer reageren dan wordt er meteen actie ondernomen, omdat dit essentieel is voor het goed (blijven) functioneren van het geheel.