[Kylix] Mening over systeem ontwerp (Threads/IPC)

[Verwijderd]

Ik ben dus bezig om een nieuw bowling score systeem te bouwen. Het is natuurlijk erg belangrijk om met een goed ontwerp te beginnen anders kom je later in de problemen.

Ik heb vorige week ook al een topic hier over geopend alleen dat was een ander ontwerp en later ging het over een discussie wat niet veel meer te maken had met mijn vraag. Daarom zet ik het nieuwe ontwerp in een nieuw topic.

Ik zou graag van jullie je mening willen horen over het ontwerp. Er zijn een aantal dingen die totaal nieuw voor mij zijn, zoals o.a. IPC. Daarom vraag ik het hier dus eerst voordat ik met een mogelijk verkeerd ontwerp ga beginnen.


Het gaat dus om een score systeem voor bowling banen. Het zal ontwikkeld worden voor het linux platform. De bedoeling is dat er 2 of 4 banen bediend gaan worden met 1 computer. Verder zal er 1 centrale computer aanwezig zijn die zo alle banen kan aansturen en informatie kan opvragen.

Een zeer belangrijk punt is dat mocht er wat fout gaan bij 1 bowling baan, de andere banen daar absoluut geen last van mogen hebben.

Een plaatje van het ontwerp kan je hier zien: Plaatje

Het systeem bestaat uit de volgende onderdelen:

- Main applicatie
- Bowling applicatie

De main applicatie wordt tijdens het opstarten van linux gestart. Dit programma zal vervolgens een aantal instellingen uitlezen uit de database die aanwezig is op de pc. In de database staat onder andere hoeveel banen de pc moet gaan bedienen en welke baannummers dat zijn.

Vervolgens zal de main applicatie x keer (dus hoeveel banen de pc moet gaan bedienen) de bowling applicatie opstarten. Hij zal dan het baannummer meesturen als parameter, zodat de bowling applicatie precies weet welke baan hij is.

Als er dus nu 1 bowling applicatie vastloopt, dan kunnen de andere mensen gewoon door bowlen zonder problemen.


Main:
In de main applicatie zit een TCPServer die multi-threaded is. Ik gebruik hiervoor de Indy TCP Server. Deze dient er dus voor om met de centrale pc te kunnen communiceren.

De InputListeningThread is een aparte "worker" thread die continu staat te kijken of er een nieuwe input is. Dit kan een joystick beweging/knop zijn of een worp (via bal detectie). Er zal dus een driver voor gebruikt worden. Deze driver wordt door een engelse programmeur momenteel gemaakt.

Delphi:

  TInputListeningThread = class(Thread)
  private
  protected
    procedure Execute; override;
  public
  end;

{ TInputListeningThread }

procedure TInputListeningThread.Execute;
begin
  while not Terminated do
  begin
    // Wacht totdat er een nieuwe input is
    // Zal dus via een read functie gaan die blocking is

    // Stuur de input door naar de juiste bowling applicatie

    Sleep(...); // anders treedt er starvation op??
  end;
end;

Als laatste komt er een MessageListeningThread in. Dit zal ook een aparte "worker" thread zijn, die continu aan het kijken is of er berichten in message queue staan. Ik dacht er aan om System V Message Queue als IPC methode te gebruiken. Zodra er een bericht is, zal deze opgehaald worden en verder afgehandeld worden.

Delphi:

  TMessageListeningThread = class(Thread)
  private
  protected
    procedure Execute; override;
  public
  end;

{ TMessageListeningThread }

procedure TMessageListeningThread.Execute;
begin
  while not Terminated do
  begin
    // Wacht totdat er een nieuw bericht in de message queue staat
    // Zal dus via een read functie gaan die blocking is

    // verwerk het bericht

    Sleep(...); // anders treedt er starvation op??
  end;
end;

Als de main applicatie wat wilt versturen naar 1 van de bowling applicatie's dan doet die dat door een bericht naar de message queue van de bowling applicatie te sturen.


Bowling applicatie:
Ook hier zal een TCP server draaien. Hiervoor zal ook de Indy TCP server voor gebruikt gaan worden. Normaal gesproken communiceert de centrale computer direct met de bowling applicatie's. Maar er zijn een paar commando's die door de main applicatie uitgevoerd zullen worden. De TCPServerThread op de Main, Bowling applicatie 1-4 maken dus allemaal gebruik van hetzelfde ip adres maar op verschillende poorten.

De Message Listening Thread zal hetzelfde werken als bij de main applicatie. Iedere bowling applicatie heeft dus een aparte message queue. Zo kan de applicatie op baan 1 dus iets sturen naar baan 4 door een bericht te sturen naar de message queue van bowling baan 4.


Het systeem maakt gebruik van CCD camera's om zo te kunnen zien hoeveel pins er zijn omgevallen. Aangezien er gebruik wordt gemaakt van 1 camera per banenpaar, kan het dus voorkomen dat zowel baan 1 als baan 2 tegelijk een foto (capture) willen opvragen. Ik zal daarom gebruik gaan maken van Video For Linux II omdat het hierbij mogelijk is om tegelijkertijd een foto op te vragen. (Bij Video For Linux I is het niet mogelijk als 2 applicaties de driver (/dev/video0) tegelijk willen openen)


Graag hoor ik het commentaar op dit ontwerp.....


[edit]
Er zal steeds communicatie plaats vinden tussen de main applicatie en de bowling applicatie's. De main applicatie stuurt om de zoveel tijd een "alive" bericht. Als de bowling applicatie dan geen ACK terug stuurt, zal de main de bowling applicatie killen en vervolgens de applicatie opnieuw starten.

[ Voor 4% gewijzigd door Verwijderd op 17-03-2003 07:29 ]

[Verwijderd]

Niemand? (Het zal toch niet zijn dat dit al het juiste ontwerp is )

[Verwijderd]

Ik zou een duidelijk ontwerp maken in RUP en UML en daarmee verder werken. Weet je precies waar je aan toe bent.

[curry684]

Ik heb een idee... je hebt nu al zoveel topics geopend over dit onderwerp (en in het algemeen ook) dat het je nieuw in de oren zal klinken. Ik zie dat je student bent op de HIO, en dan zie ik 2 mogelijkheden:
• Dit is een opdracht voor school. In dat geval raad ik je aan om eens in je boeken en/of bij je docenten te rade te gaan over wat een goed ontwerp is en welke methodieken je daarbij kunt gebruiken.
• Of je doet dit als klusje erbij in je sparetime. In dat geval wil ik je aanraden de hulp van een betaalde professional in te roepen.

Als ik door je posthistory blader zie ik 813 postings in 276 topics waarvan je ongeveer 80-85% zelf gestart bent. Dat heet helpdesken: het gebruik maken van een forum als gratis handige vraagbaak zonder dat je er zelf energie in terugstopt om het beter te maken. De meeste helpdeskers leren na enkele tientallen vragen vanzelf dat ze ook zelf in topics kunnen helpen, dit is helaas bij jou na ruim 2 jaar nog niet begonnen door te dringen. Misschien dat ik het even moet verduidelijken: GoT is geen helpdesk, het is een community.

Helaas is het enige wapen dat ik als user tegen je in kan zetten een dikke ignore op je topics, die kun je bij deze als ingezet beschouwen.

[martijn_brinkers]

Ik heb verder niet veel opmerkingen. Alleen deze 2

// Wacht totdat er een nieuw bericht in de message queue staat
// Zal dus via een read functie gaan die blocking is

// verwerk het bericht

Sleep(...); // anders treedt er starvation op??

Als de read functie blocking is, zoals je zelf schrijft, hoeft die sleep() niet. Sleep is zowiezo eigenlijk in bijna alle gevallen af te raden en is vaker een indicatie van een slecht doordacht ontwerp. Als ik ergens Sleep in combinatie met threads zie beginnen bij mij de alarmbellen te rinkelen.
Ik zou verder zoveel mogelijk gebruik maken van standaard technieken. Dus zoveel mogelijk tcp/ip en niet teveel gebruik maken van messaging op OS niveau. Je systeem wordt zodoende meer portable.

[Verwijderd]

curry684 schreef op 17 maart 2003 @ 20:07:Ik heb een idee... je hebt nu al zoveel topics geopend over dit onderwerp (en in het algemeen ook)

Ik heb eerst een topic geopend over een bepaald ontwerp (threads met aparte formulieren) en waarna het topic meer over een scheld partij ging tussen 2 mensen op dit forum dan over mijn vraag. Tevens heb ik een topic geplaatst om te vragen naar de praktijk ervaring van IPC vormen aangezien dit nieuw voor mij is. Uiteindelijk hebben we een nieuw ontwerp gemaakt en aangezien het 1e topic later over een andere discussie ging heb ik besloten om hiervoor een nieuw topic te openen.

Ik zie dat je student bent op de HIO, en dan zie ik 2 mogelijkheden:
• Dit is een opdracht voor school. In dat geval raad ik je aan om eens in je boeken en/of bij je docenten te rade te gaan over wat een goed ontwerp is en welke methodieken je daarbij kunt gebruiken.
• Of je doet dit als klusje erbij in je sparetime. In dat geval wil ik je aanraden de hulp van een betaalde professional in te roepen.

Ik ben bezig met mijn afstudeeropdracht bij een bedrijf. Hier moet een nieuw bowling systeem ontwikkeld worden. Van o.a. IPC heb ik nog geen verstand, dus daarom vraag ik het eerst hier (nadat ik een boek erover gelezen heb. Maar aan de praktijk ervaring heb je vaak veel meer dan alleen maar de theorie uit het boek).

Als ik door je posthistory blader zie ik 813 postings in 276 topics waarvan je ongeveer 80-85% zelf gestart bent. Dat heet helpdesken: het gebruik maken van een forum als gratis handige vraagbaak zonder dat je er zelf energie in terugstopt om het beter te maken. De meeste helpdeskers leren na enkele tientallen vragen vanzelf dat ze ook zelf in topics kunnen helpen, dit is helaas bij jou na ruim 2 jaar nog niet begonnen door te dringen. Misschien dat ik het even moet verduidelijken: GoT is geen helpdesk, het is een community.

Ik weet alleen een beetje de basis vaardigheden van Delphi. Aangezien ik niet iemand ben die iedere seconde een refresh doe op het forum om te kijken of er een nieuwe vraag is, die ik mogelijk zou kunnen beantwoorden, is altijd al iemand voor mij, omdat er volgens mij mensen zijn hier die ongeveer 30 keer per minuut de pagina refreshen. Sorry.

[martijn_brinkers]

vragen staat vrij dus trek je er niet veel van aan. Mijn definitie van community is denk ik een andere dan die curry heeft. Vergeet niet dat door de vragen die jij stelt en de antwoorden die daarop volgen andere forum members die nooit iets posten ook veel leren. Dus doordat jij veel vragen stelt draag je in belangrijke mate bij aan de community. Ga dus vooral door.

[Verwijderd]

TijnFLiP schreef op 17 March 2003 @ 21:36:
vragen staat vrij dus trek je er niet veel van aan. Mijn definitie van community is denk ik een andere dan die curry heeft. Vergeet niet dat door de vragen die jij stelt en de antwoorden die daarop volgen andere forum members die nooit iets posten ook veel leren. Dus doordat jij veel vragen stelt draag je in belangrijke mate bij aan de community. Ga dus vooral door.

Ja zo denk ik er dus ook over.

[supakeen]

TijnFLiP schreef op 17 March 2003 @ 21:36:
vragen staat vrij dus trek je er niet veel van aan. Mijn definitie van community is denk ik een andere dan die curry heeft. Vergeet niet dat door de vragen die jij stelt en de antwoorden die daarop volgen andere forum members die nooit iets posten ook veel leren. Dus doordat jij veel vragen stelt draag je in belangrijke mate bij aan de community. Ga dus vooral door.

Ben toch even heel erg benieuw naar jouw definitie van community, mensen stellen hier vragen, inderdaad. Maar niet constant vragen over hetzelfde en meer vragen dan het helpen van andere users.

In het echt is het ook asociaal als ik alleen tegen jou praat en jou nauwelijks laat terugpraten?

[Glimi]

Zal ik er dan maar neerzetten hoe de /14 mods het beleid ervan gemaakt hebben? Da's namelijk imho het enige relevante binnen deze kwestie

Helpdesken wordt pas aangepakt door moderators als de vragen die de topicstarter stelt beneden de maat zijn. Vragen als "los ff op", "doe ff dit", kortom 'quick-fix' vragen waarbij geen moeite is gedaan door de TS worden aangepakt. Dit omdat deze vragen uitermate storend zijn doordat de persoon niet lijkt te willen leren, maar slechts te teren op andermans kennis.

Het geval van tokkie is een ander geval (en hier is het beleid een tijd geleden over omgeslagen hoor ) Tokkie gebruikt GoT meer als resource, niet als helpdesk. Als hij een vraag stelt, zit daar voldoende onderzoek en eigen initiatief achter. Dit concludeer ik 1-2-3 aan het aantal slotjes in de posthistory, kortom geen grond om tokkie aan te gaan pakken.

Persoonlijke noot is wel, dat een community een kwestie van geven en nemen is. We kunnen een persoon niet verplichten tot 'geven', maar het draagt wel bij aan het gevoel.

Verdere discussie in dit topic is niet nodig. If so, open dan een topic in LA of mail me maar
ontopic plz

[curry684]

Ik hap nog wel even. Dit zijn de vorige ZEVEN topics van tokkie:
• PW [Kylix] Mening over systeem ontwerp (Threads/IPC) tokkie 8 17-03-2003 21:52
• PW [Kylix] Communicatie tussen programma's tokkie 19 16-03-2003 19:24
• PW [Kylix] Multi threaded applicatie tokkie 40 12-03-2003 13:13
• PW [Kylix] Bitmap wordt niet goed getoond i.c.m. scanline tokkie 20 05-03-2003 14:11
• NOS [Linux] Video4Linux I of II tokkie 7 03-03-2003 10:58
• PW [Kylix] RGB waarden uit geheugen in een plaatje zetten tokkie 0 27-02-2003 14:09
• PW [Kylix] Video4Linux interface tokkie 19 27-02-2003 14:06

7 topics in 3 weken over exact hetzelfde project, en vrijwel allemaal bevatten ze meerdere vragen over hetzelfde project.

Van mij mogen mensen hier best veel vragen stellen als ze echt vast zitten en er proberen uit te komen. Tokkie zit hier echter voor z'n afstudeeropdracht te sprokkelen naar gratis consultancy. Uberhaupt nogal tegenstrijdig is dat noch hij noch blijkbaar zijn begeleiders ook maar de ballen verstand blijken te hebben van de materie, wat als ik er iets mee van doen had zou resulteren in een onvoldoende voor de student en een waarschuwing aan het bedrijf dat blijkbaar goedkoop een nieuw stuk software in te kopen.

GoT is tot nu ingeschakeld als beslissende instantie bij iedere designbeslissing die er gemaakt moest worden voor dit commerciele project, dat is heel wat anders dan hulp vragen bij een probleempje voor je hobbyproject.

Als je een professioneel C++ architect/consultant nodig hebt mag je me best een mailtje sturen, maar dan krijg je ook een factuur terug.

[martijn_brinkers]

Oke laat ik ermee beginnen dat ik niet een duidelijk omschreven definitie heb van een community. Alleen al omdat dit kan resulteren in een oerverloze discussie over wat er wel en niet in de definitie hoort. Ik zelf vind het niet irritant dat iemand alleen maar vragen stelt. Liever mensen die vragen stellen dan mensen die niks zeggen. Zoals ik al zei, leeft een community van interactie, en het stellen van vragen is het startpunt van interactie.

[Verwijderd]

Wat me opvalt is dat je, Curry684, nogal snel geirriteerd reageerd. Bijv ook in mijn vorige topic tegen iemand anders:

Tering jij hebt de klok heel hard horen luiden maar de klepel hangt ergens op een andere planeet of zo


Ik heb liever gewoon dat er dan niet gereageerd wordt, dan zulke antwoorden te geven. Doe dan gewoon net als wat je zei, gewoon negeren i.p.v. zulke opmerkingen gaan plaatsen waar niemand wat aan heeft.

[Glimi]

Hoezeer praat ik een andere taal dan Nederlands?

quote: http://gathering.tweakers...message/17296834#17296834

Verdere discussie in dit topic is niet nodig. If so, open dan een topic in LA of mail me maar
ontopic plz

[brokenp]

FF Ontopic
Ik weet hier niet zo veel vanaf, maar toch begrijp ik het nut niet helemaal van de verbinding tussen de app's die op de verschillende banen draaien

De Message Listening Thread zal hetzelfde werken als bij de main applicatie. Iedere bowling applicatie heeft dus een aparte message queue. Zo kan de applicatie op baan 1 dus iets sturen naar baan 4 door een bericht te sturen naar de message queue van bowling baan 4.

Wat voor berichten verwacht je hier??
Of gaat het hier om het bepalen van de winnaar ofzo??(zou je dat dan niet in je main app doen?)

Voor de rest lijkt mij dit ontwerp wel goed.

[Verwijderd]

brokenp schreef op 17 March 2003 @ 22:50:Wat voor berichten verwacht je hier??
Of gaat het hier om het bepalen van de winnaar ofzo??(zou je dat dan niet in je main app doen?)

Bij bowlen wordt ook het amerikaanse systeem gespeeld. Dit houdt in dat iedere bowler na een frame gegooid te hebben wisselt van baan (mensen van baan 1 gaan naar 2 en mensen op baan 2 gaan naar baan 1). Alle informatie over de spelers en scores moeten dus doorgestuurd worden naar de andere applicatie waar deze gegevens vervolgens getoond zullen worden op de monitor.

[farlane]

Verwijderd schreef op 18 maart 2003 @ 07:31:
[...]
Bij bowlen wordt ook het amerikaanse systeem gespeeld. Dit houdt in dat iedere bowler na een frame gegooid te hebben wisselt van baan (mensen van baan 1 gaan naar 2 en mensen op baan 2 gaan naar baan 1). Alle informatie over de spelers en scores moeten dus doorgestuurd worden naar de andere applicatie waar deze gegevens vervolgens getoond zullen worden op de monitor.

Is het dan niet handig om de scores in een centrale db - taak op te slaan ?

[Verwijderd]

farlane schreef op 18 March 2003 @ 09:49:Is het dan niet handig om de scores in een centrale db - taak op te slaan ?

Het wordt zoiezo al opgeslagen in de database.

Maar er zal een seintje gegeven moeten worden (dus communicatie) naar de andere applicatie om te zeggen dat de spelers wisselen van baan.

[Verwijderd]

Maar we hebben weer ff contact gehad met de engelse kerel die de driver (communiceert met de hardware: joystick, bal detectie, bowling machine, enz...) voor ons gaat maken en we hebben het zelf hier nog ff over gehad over het ontwerp.

We gaan het toch anders doen.

Het idee van 1 main applicatie en 2-4 bowling applicatie's blijft. Echter we gaan geen IPC technieken meer gebruiken, aangezien we er al problemen mee hebben dat het niet werkt (System V Message Queue werkt niet op ons systeem en hebben contact gehad met de kerel van dat boek en die vertelde ons dat er al meer mensen zijn met hetzelfde probleem en dat het mogelijk kan leggen aan een andere glibc versie. Als nu al blijkt dat het problemen oplevert is het misschien niet verstandig om er mee door te gaan).

We hebben toch besloten om gebruik te gaan maken van sockets. Zoiezo zouden we al bij zowel de main als de bowling applicatie's een TCPServer implementeren vanwege de communicatie met de centrale pc. Normaal gesproken zou IPC logischer zijn om te communiceren tussen de verschillende applicatie's maar we kiezen toch voor de TCP, omdat die al aanwezig is. Het zal wat meer overhead zijn maar dat nemen we voor lief (Echter dat zal je zeer waarschijnlijk niet eens merken).

Ook het capturen zullen we gaan verplaatsen naar de main applicatie. Op de main applicatie was zoiezo al het gedeeltje aanwezig dat steeds aan het pollen is om te kijken of er een bal gegooid is. Na een bal detectie zal hier de foto gemaakt worden, score berekend worden en uiteindelijk zal alleen de score doorgestuurd worden. De main applicatie regelt het dus nu allemaal en hoeven we ook geen V4L2 meer te gaan gebruiken, wat er voor zou zorgen dat meerdere processen tegelijkertijd zouden kunnen capturen.

Heel het input(joystick, bal detectie) en output (bijv. cyclen bowling machine) gebeuren zal ook via de main gaan, zodat niet meerdere applicaties de device driver tegelijkertijd zouden moeten kunnen openen.