Stel je voor er is een systeem dat bestaat uit de volgende componenten:
- Camera's die gezichten scannen op een bepaalde locatie. Dit noemen we Source. (Het aantal camera's is niet relevant omdat dit on the fly moet kunnen worden uitgebreid).
- Camera Logica die de gescande gezichten vergelijkt met gezochte personen en hieruit 'Hits' genereert.
- Clients die van één of meerdere camera's het resultaat ontvangen.
- Een Server die alle data (foto's + foto info als tijdstip, locatie + info over 'hits' zoals 'waarom gezocht', 'sinds wanneer' etc.) van de Camera Logica ontvangt en opslaat en routeert naar de clients
Bijvoorbeeld:
In Rotterdam Centraal Station staan twee camera's, op de beveiligingspost 'abonneert' men de clients dus op die twee camera's.
In Amsterdam CS staan 4 camera's, op de beveiligingspost 'abonneert' men de clients dus op die vier camera's.
In Utrecht op de Centrale 'abonneert' men de clients soms op alle zes camera's tegelijkertijd.
Samenvattend bestaat de situatie dus uit:
6 Camera's;
Een of meerdere Camera Servers met Logica;
Een Centrale Server, die data opslaat en routering regelt
Clients die zich abonneren op Camera's, en data ontvangen van de Centrale server.
Hoe zou je het Client - Server verhaal nou inrichten?
Zou je de clients laten pollen bij de Centrale Server iedere seconde om te kijken of er nieuwe 'hits' voor de specifieke client beschikbaar zijn,
Of zou je de Centrale Server data laten sturen naar de clients zodra er nieuwe data voor ze beschikbaar is.
Mijn voorkeur gaat uit naar de laatste optie, maar als ik zo eens rondkijken naar voorbeelden dan kom ik al snel uit bij chat-achtige oplossingen. De voorbeelden hiervan geven aan dat er 1 centrale chatserver is waarop chatclients inloggen. De chatclients kijken dan iedere halve seconde of er nieuwe berichten zijn op de server. Maar dat lijkt me maar een vage oplossing.
- Camera's die gezichten scannen op een bepaalde locatie. Dit noemen we Source. (Het aantal camera's is niet relevant omdat dit on the fly moet kunnen worden uitgebreid).
- Camera Logica die de gescande gezichten vergelijkt met gezochte personen en hieruit 'Hits' genereert.
- Clients die van één of meerdere camera's het resultaat ontvangen.
- Een Server die alle data (foto's + foto info als tijdstip, locatie + info over 'hits' zoals 'waarom gezocht', 'sinds wanneer' etc.) van de Camera Logica ontvangt en opslaat en routeert naar de clients
Bijvoorbeeld:
In Rotterdam Centraal Station staan twee camera's, op de beveiligingspost 'abonneert' men de clients dus op die twee camera's.
In Amsterdam CS staan 4 camera's, op de beveiligingspost 'abonneert' men de clients dus op die vier camera's.
In Utrecht op de Centrale 'abonneert' men de clients soms op alle zes camera's tegelijkertijd.
Samenvattend bestaat de situatie dus uit:
6 Camera's;
Een of meerdere Camera Servers met Logica;
Een Centrale Server, die data opslaat en routering regelt
Clients die zich abonneren op Camera's, en data ontvangen van de Centrale server.
Hoe zou je het Client - Server verhaal nou inrichten?
Zou je de clients laten pollen bij de Centrale Server iedere seconde om te kijken of er nieuwe 'hits' voor de specifieke client beschikbaar zijn,
Of zou je de Centrale Server data laten sturen naar de clients zodra er nieuwe data voor ze beschikbaar is.
Mijn voorkeur gaat uit naar de laatste optie, maar als ik zo eens rondkijken naar voorbeelden dan kom ik al snel uit bij chat-achtige oplossingen. De voorbeelden hiervan geven aan dat er 1 centrale chatserver is waarop chatclients inloggen. De chatclients kijken dan iedere halve seconde of er nieuwe berichten zijn op de server. Maar dat lijkt me maar een vage oplossing.
[ Voor 5% gewijzigd door Verwijderd op 03-06-2005 19:29 ]