Interactie high-level / low-level

dinsdag 26 november 2013 09:30

Alhoewel ik de RDBMS niet verkeerd vind (je wilt toch ergens bijhouden wat nu welke status heeft al is het enkel maar om een dashboard te tonen) zou ik die toch enkel gebruiken voor het archiveren / bewaren van de data voor je applicatie en niet voor data-opslag waar je "driver" dan in kan gaan zitten wroeten.

In principe zou ik je driver gewoon helemaal niet laten pollen maar je moet daarheen iets pushen en je driver moet enkel die push opvangen en daar naargelang de inhoud iets mee doen.
Hoe je die push dan wilt laten verlopen is helemaal aan jou, je kan een eigen socket systeem opzetten maar er zijn ook tientallen (zoniet honderden) push-implementaties voor lokaal te vinden.

Het enige grote probleem wat ik zo snel zie is dat je redelijk low-level lijkt te werken en dat als je dan wil gaan pushen je eigenlijk een 2-wegs communicatie moet hebben (je moet echt een bevestiging krijgen dat je push ontvangen is maar ook verwerkt richting de seriele poort en eigenlijk ook of het domotica apparaat dan erop gereageerd heeft) want een push is eenmalig en als er dan iets fout gaat op het seriele lijntje dan brand je lamp gewoon niet. Terwijl je nu waarschijnlijk gewoon bij elke poll-actie het signaal opnieuw verstuurt waardoor als het 1e signaal niet aankomt het 2e (of 3e of 4e) dat vast wel doet.

Acties:

peterkuli

Topicstarter

Dank voor de antwoorden! De termen die genoemd zijn geven me nu al meer inzicht, waarvan IPC mij heeft geleid tot de term pipe. Dit lijkt mij zeker de moeite waard om eens beter naar te kijken. Ook message queue lijkt interessant en kan met zowel PHP als C. Sockets zijn in mijn applicatie iets minder geschikt omdat ik straks al met sockets ga werken, maar dan aan de bus-kant. Ik moet dan al een server en client implementeren (voor zenden naar en ontvangen van de bus) en als ik ook nog eens een socket moet gaan maken voor communicatie met de webapp lijkt het me onnodig gecompliceerd te worden.

@Gomez12; klopt, er zit nu een mechanisme in dat de status controleert, indien nodig wordt het commando vaker verzonden totdat de gewenste status is bereikt. Als ik het even snel bekijk lijkt het me wel mogelijk om middels pipes of message queue een constructie te krijgen dat ik bevestiging van de bus naar de webapp krijg.

dinsdag 26 november 2013 10:24

Acties:

dinsdag 26 november 2013 12:53

Via pipes of message queue krijg je idd ook makkelijk een bericht terug, het is meer de vraag of je bus het kan produceren...

Acties:

Bigs

In plaats van deze communicatie via een database te gebruiken zou je inderdaad beter een messaging systeem kunnen gebruiken. Low level sockets of IPC zijn veel werk en bieden je flexibiliteit die je niet nodig hebt. Een losse broker (RabbitMQ, Redis pubsub, etc. keus zat) is aan de andere kant ook weer overkill. Zelf ben ik de laatste tijd bezig met ZeroMQ, dit is een leuke middenweg.

Zoals ze het zelf beschrijven:

ØMQ (also known as ZeroMQ, 0MQ, or zmq) looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. It's fast enough to be the fabric for clustered products. Its asynchronous I/O model gives you scalable multicore applications, built as asynchronous message-processing tasks. It has a score of language APIs and runs on most operating systems. ØMQ is from iMatix and is LGPLv3 open source.

Hiermee zou je heel eenvoudig communicatie tussen je front- en backend kunnen opzetten.

ØMQ - The Guide

dinsdag 26 november 2013 14:05

Acties:

dinsdag 26 november 2013 15:38

I doubt, therefore I might be

Een andere mogelijke optie is het opzetten van een sqlite databaseje. Dat kan in PHP heel gemakkelijk in-process met de sqlite extensie. Je hebt dan niet de overhead van een externe RDBMS, maar toch de flexibiliteit van gestructureerde data, SQL en persistency.

Klik hier om mij een DM te sturen • 3245 WP op ZW

Acties:

dinsdag 26 november 2013 16:11

Moderator Devschuur®

!litemod

Aan een in-process sqlite heb je natuurlijk heel weinig wanneer die database vervolgens ook nog eens uitgelezen moet worden door het C programma. Daarnaast lost dat het grootste bezwaar (constant pollen van de DB om naar wijzigingen te zoeken) niet op.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

Mijzelf

peterkuli schreef op maandag 25 november 2013 @ 22:56:
(een ander voorbeeld van high-level naar low-level zijn de instelling-pagina's op routers e.d. Hierin is het vaak ook mogelijk om vanuit de webapp een router opnieuw op te starten, wat duidelijk een low-level bewerking is. Hoe wordt dit gedaan?)

Bij de routers die ik heb bekeken draait de webserver als root, en worden commando's via een cgi binary uitgevoerd.

dinsdag 26 november 2013 16:35

Acties:

dinsdag 26 november 2013 16:44

Mijzelf schreef op dinsdag 26 november 2013 @ 16:11:
[...]

Bij de routers die ik heb bekeken draait de webserver als root, en worden commando's via een cgi binary uitgevoerd.

Je hebt nog wel enkele routers die als user draaien en commando's doorgeven aan een los proces wat als root draait en wat de commando's weer omzet naar systeemcommando's maar dan zit je over het algemeen wel in het duurdere segment (de gedachte erachter is dat je enkel het losse proces hoeft te bewaken en niet de complete webserver core, het losse proces kan dan enkel enkele commando's aan en voor de webserver kan je gewoon een algemeen pakket pakken)

Acties:

dinsdag 26 november 2013 16:57

I doubt, therefore I might be

Janoz schreef op dinsdag 26 november 2013 @ 15:38:
Aan een in-process sqlite heb je natuurlijk heel weinig wanneer die database vervolgens ook nog eens uitgelezen moet worden door het C programma. Daarnaast lost dat het grootste bezwaar (constant pollen van de DB om naar wijzigingen te zoeken) niet op.

Met in-process bedoel ik de database engine van sqlite. De database zelf is uiteraard wel vanuit meerdere processen te benaderen. En door de database op de Linux ramdisk (tempfs, /dev/shm) te zetten, hou je 'm effectief in shared memory zonder "dure" file IO te hoeven doen. Dat is ontzettend licht. Zelfs al query je 100 keer per seconde, dan blijf je zeer waarschijnlijk nog onder de 1% cpu belasting (mits er op correcte wijze tussen de polling de wachttijd aan de CPU teruggegeven wordt).

Klik hier om mij een DM te sturen • 3245 WP op ZW

Acties:

dinsdag 26 november 2013 17:31

Moderator Devschuur®

!litemod

DexterDee schreef op dinsdag 26 november 2013 @ 16:44:
[...]

Met in-process bedoel ik de database engine van sqlite. De database zelf is uiteraard wel vanuit meerdere processen te benaderen. En door de database op de Linux ramdisk (tempfs, /dev/shm) te zetten, hou je 'm effectief in shared memory zonder "dure" file IO te hoeven doen. Dat is ontzettend licht. Zelfs al query je 100 keer per seconde, dan blijf je zeer waarschijnlijk nog onder de 1% cpu belasting (mits er op correcte wijze tussen de polling de wachttijd aan de CPU teruggegeven wordt).

MySQL kan (en doet) precies hetzelfde. Er is geen performance verschil. Je introduceert echter wel een probleem. Doordat de engine geheel binnen php draait wordt het erg lastig voor het C deel om betrouwbaar die databas uit te kunnen lezen. Twee instanties van sqlite die naar het zelfde bestand proberen te schrijven gaat natuurlijk voor corruptie, of overmatig locken via het filesystem leiden.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

dinsdag 26 november 2013 19:57

I doubt, therefore I might be

Met alle respect Janoz, maar Sqlite en MySQL doen het niet precies hetzelfde. Er is een embedded versie van MySQL die je in je applicatie kan compilen, maar daar hebben we het hier niet over. MySQL acteert in een standaardopstelling als een apart proces. Sqlite acteert als embedded database engine in het PHP proces.

Qua betrouwbaarheid maakt het niet bijzonder veel uit of er een embedded of een standalone database engine gebruikt wordt. De Sqlite implementatie is threadsafe gecompiled in de PHP extensie en is specifiek gemaakt om betrouwbaar en snel te werken in een (low-)concurrency omgeving. En daar hebben we het over, aangezien we maar met twee threads naar de database connecten. Slechts bij het schrijven naar de Sqlite database zal er file locking plaatsvinden, alle leesacties worden concurrent zonder locking uitgevoerd.

Je zegt ook dat er geen performance verschil is. Daar vergis je je in. Met een Sqlite database op mijn laptop haal ik op een tabel met 100k records al zo'n 70.000 queries / sec. Daar komt MySQL bij lange na niet bij in de buurt. Door deze snelheidskarakteristiek heb ik deze constructie wel eens ingezet op geclusterde PHP applicatieservers als lokale lookup cache. Zelfs bij meer dan 100 concurrent threads naar de Sqlite database blijft de boel gewoon stabiel. Het is niet zo dat ik aannames maak, ik heb hier daadwerkelijk ervaring mee op productieomgevingen.

Klik hier om mij een DM te sturen • 3245 WP op ZW

Acties:

PrisonerOfPain

peterkuli schreef op maandag 25 november 2013 @ 22:56:
Hoewel de applicatie goed werkt vraag ik me af of een dergelijke constructie vaker voorkomt (en daarmee de 'juiste' werkwijze is) of dat deze zaken ook op een andere manier opgelost kunnen worden. Persoonlijk vind ik deze oplossing namelijk niet heel mooi. Ik kan niet precies zeggen waarom niet maar op een of andere manier voelt het niet solide aan.

Je hebt zo te zien een leuke discussie opgewakkert die bij een hoop mensen een hoop verschillende ideeen oproepen (xmlrpc, message brokers, ipc, etc). Maar je moet een paar dingen in de gaten houden, die verschillende technieken zorgen alleen maar voor extra "moving parts" of "points of failure" leuk dat ze bestaan maar zolang je ze echte extra waarde toevoegen kunnen ze alleen maar kapot gaan.

Jammer dat de bestaande oplosssing niet in het straatje "mooie enterprise oplossingen" valt - en waarschijnlijk zelfs een heel stuk daar buiten. Maar zolang jij niet kunt bedenken wat er mis is met de huidige oplossing, behalve dat het niet "solide aanvoelt", hoeft er natuurlijk niks te veranderen.

Echter, als je wel aan kunt wijzen dat er concrete problemen zijn die je tegen komt dan kun je een heel stuk gerichter op zoek gaan naar een oplossing. Kortom, zoek eerst een probleem, voor je naar een oplossing zoekt

dinsdag 26 november 2013 20:15

Acties:

dinsdag 26 november 2013 20:29

peterkuli schreef op maandag 25 november 2013 @ 22:56:
(een ander voorbeeld van high-level naar low-level zijn de instelling-pagina's op routers e.d. Hierin is het vaak ook mogelijk om vanuit de webapp een router opnieuw op te starten, wat duidelijk een low-level bewerking is. Hoe wordt dit gedaan?)

Dat kan bijvoorbeeld met CGI, veel eenvoudiger dan dat wordt het niet.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

Acties:

dinsdag 26 november 2013 23:53

Moderator Devschuur®

!litemod

DexterDee schreef op dinsdag 26 november 2013 @ 17:31:
Met alle respect Janoz, maar Sqlite en MySQL doen het niet precies hetzelfde. Er is een embedded versie van MySQL die je in je applicatie kan compilen, maar daar hebben we het hier niet over. MySQL acteert in een standaardopstelling als een apart proces. Sqlite acteert als embedded database engine in het PHP proces.

Qua betrouwbaarheid maakt het niet bijzonder veel uit of er een embedded of een standalone database engine gebruikt wordt. De Sqlite implementatie is threadsafe gecompiled in de PHP extensie en is specifiek gemaakt om betrouwbaar en snel te werken in een (low-)concurrency omgeving. En daar hebben we het over, aangezien we maar met twee threads naar de database connecten. Slechts bij het schrijven naar de Sqlite database zal er file locking plaatsvinden, alle leesacties worden concurrent zonder locking uitgevoerd.

Je zegt ook dat er geen performance verschil is. Daar vergis je je in. Met een Sqlite database op mijn laptop haal ik op een tabel met 100k records al zo'n 70.000 queries / sec. Daar komt MySQL bij lange na niet bij in de buurt. Door deze snelheidskarakteristiek heb ik deze constructie wel eens ingezet op geclusterde PHP applicatieservers als lokale lookup cache. Zelfs bij meer dan 100 concurrent threads naar de Sqlite database blijft de boel gewoon stabiel. Het is niet zo dat ik aannames maak, ik heb hier daadwerkelijk ervaring mee op productieomgevingen.

Er zijn echter 2 punten die je over het hoofd ziet. De engine draait binnen php. De situatie van de topicstarter heeft echter ook een non php proces welke ook bij de database moet. Dan heb je vervolgens verschillende instanties die met dezelfde files willen werken.

Uiteraard is er een overhead verschil aangezien de MySQL oplossing eerst alle data door een socket moet sturen terwijl sqlite de data beschikbaar heeft in dezelfde geheugenruimte als het php proces. Maar dat voordeel gaat hier niet op vanwege het losstaande C programma wat bij dezelfde data moet kunnen.

Maar het grootste probleem is dat je het daadwerkelijke probleem niet oplost. Het hele aansturen is zo snel als de poll interval. Zet je die op een tiende van een seconden dan reageert het systeem merkbaar traag, maar ondertussen wordt er bijna een miljoen keer een poll query op de database gedaan voor die paar keer dat het licht aan of uit gaat. Dan kun je die query gaan optimaliseren, maar ik hoop dat je zelf ook inziet dat het misschien handiger is om de wijzigingen de pushen naar het C programma.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

Soultaker

Janoz schreef op dinsdag 26 november 2013 @ 20:29:
Er zijn echter 2 punten die je over het hoofd ziet. De engine draait binnen php. De situatie van de topicstarter heeft echter ook een non php proces welke ook bij de database moet. Dan heb je vervolgens verschillende instanties die met dezelfde files willen werken.

Ik denk dat er een misverstand is over hoe SQLite werkt. De “engine” is gewoon een library; per definitie draait die binnen het proces dat de library gebruikt, maar verschillende processen kunnen probleemloos op dezelfde database werken; dat is één van de use-cases waar SQLite specifiek voor ontworpen is.

Dat verschillende processen elk hun eigen kopie van de “engine” in hun address space hebben maakt niet uit; die processen coördineren toegang tot de database files via locking, maar hoe dat precies werkt daar hoef je je als gebruiker niet druk over te maken.

Het is dus niet zo dat als je de database vanuit PHP updatet het C programma vervolgens met het PHP proces moet verbinden ofzo omdat “de engine binnen PHP draait”. Het C programma heeft te allen tijden een consistente en up-to-datete view van de database omdat SQLite zorgt dat updates naar de gedeelde database file worden geschreven.

[ Voor 15% gewijzigd door Soultaker op 26-11-2013 23:57 ]

woensdag 27 november 2013 08:16

Acties:

peterkuli

Topicstarter

PrisonerOfPain schreef op dinsdag 26 november 2013 @ 19:57:
[...]
Echter, als je wel aan kunt wijzen dat er concrete problemen zijn die je tegen komt dan kun je een heel stuk gerichter op zoek gaan naar een oplossing. Kortom, zoek eerst een probleem, voor je naar een oplossing zoekt

Nee, er zijn geen concrete problemen. Het enige probleem is mijn gevoel dat de oplossing zoals ik die heb op een of andere manier niet 'goed' of 'solide' aanvoelt. Ik vraag me gewoon af (en gaf dat aan in OP) wat de 'gangbare' manieren zijn om dergelijke dingen te doen omdat ik zelf geen andere ideeën had hoe het anders zou kunnen.

woensdag 27 november 2013 09:04

Acties:

woensdag 27 november 2013 09:45

Ik heb het idee dat dat gevoel veroorzaakt wordt doordat het een polling mechanisme is, of heb ik dat fout? In ieder geval is met polling niets mis zo lang je niet qua performance in problemen komt. Groot voordeel is dat het super eenvoudig is.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

Acties:

woensdag 27 november 2013 11:21

Moderator Devschuur®

!litemod

Soultaker schreef op dinsdag 26 november 2013 @ 23:53:
[...]

Ik denk dat er een misverstand is over hoe SQLite werkt. De “engine” is gewoon een library; per definitie draait die binnen het proces dat de library gebruikt, maar verschillende processen kunnen probleemloos op dezelfde database werken; dat is één van de use-cases waar SQLite specifiek voor ontworpen is.

Dat verschillende processen elk hun eigen kopie van de “engine” in hun address space hebben maakt niet uit; die processen coördineren toegang tot de database files via locking, maar hoe dat precies werkt daar hoef je je als gebruiker niet druk over te maken.

Maar even voor mijn beeldvorming, door het gebruik van filelocking en het uitwisselen van data via het filesystem is het snelheidsvoordeel toch een stuk kleiner? Ik ken sqllite en heb het wel eens gebruikt, maar heb op het gebied van embedable databases meer ervaring met hsqldb.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

woensdag 27 november 2013 14:21

Janoz schreef op woensdag 27 november 2013 @ 09:45:
Maar even voor mijn beeldvorming, door het gebruik van filelocking en het uitwisselen van data via het filesystem is het snelheidsvoordeel toch een stuk kleiner?

Ongetwijfeld worden dingen gecached door het OS dus het zal niet zo zijn dat je op de platters van je HD staat te wachten.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

Acties:

peterkuli

Topicstarter

farlane schreef op woensdag 27 november 2013 @ 09:04:
Ik heb het idee dat dat gevoel veroorzaakt wordt doordat het een polling mechanisme is, of heb ik dat fout?

Klopt.

In ieder geval is met polling niets mis zo lang je niet qua performance in problemen komt. Groot voordeel is dat het super eenvoudig is.

Performance is geen issue, het systeem an sich is snel zat. Eenvoudig is het inderdaad ook. Het is inderdaad ook niet zo dat er iets niet werkt, het werkt juist erg goed.

woensdag 27 november 2013 15:49

Acties:

Soultaker

Janoz schreef op woensdag 27 november 2013 @ 09:45:
Maar even voor mijn beeldvorming, door het gebruik van filelocking en het uitwisselen van data via het filesystem is het snelheidsvoordeel toch een stuk kleiner?

Dat klopt inderdaad; de datastructuren die SQLite gebruikt (B+ trees) zijn ook niet veel anders dan bijvoorbeeld MySQL wat je noemde. Het committen van een transactie is in SQLite ook niet bijster snel. Read-only queries kunnen natuurlijk wel snel zijn, zeker wanneer de relevante data deels gecached is. Overigens is het niet file locking wat het committen van transacties traag maakt, maar het syncen van het filesystem (wat elke database die de D van ACID garandeert moet doen).

SQLite kan soms wat sneller zijn dan een traditioneel RDBMS omdat queries en resultaten niet via een socket uitgewisseld hoeven worden. Dat is vooral relevant als je veel kleine queries doet. In een client-server model moet je de query marshallen, context switchen, demarshallen, query uitvoeren, resultaten marshallen, context switchen, demarshallen. Nog een paar extra context switches als er zoveel resultaten zijn dat ze niet in de socket buffer passen. Die overhead kan voor simpele queries nogal groot zijn, en in die situaties kan SQLite een stuk sneller werken. In veel applicaties zijn queries dan ook simpel; de situatie die de TS beschrijft lijkt daar een voorbeeld van te zijn.

Maar voor de duidelijkheid: SQLite is vooral “licht” in de zin dat het een simpelere architectuur mogelijk maakt: je hoeft geen aparte databaseserver te configureren, niet te prutsen met sockets en authenticatie of het starten/stoppen van de server bij het booten, en toch heb je beschikking over een groot deel van de features die een RDBMS biedt. Dat is uiteindelijk het fundamentele voordeel van SQLite.

[ Voor 7% gewijzigd door Soultaker op 27-11-2013 15:53 ]

woensdag 27 november 2013 17:13

Acties:

woensdag 27 november 2013 17:31

Moderator Devschuur®

!litemod

Soultaker schreef op woensdag 27 november 2013 @ 15:49:

Maar voor de duidelijkheid: SQLite is vooral “licht” in de zin dat het een simpelere architectuur mogelijk maakt: je hoeft geen aparte databaseserver te configureren, niet te prutsen met sockets en authenticatie of het starten/stoppen van de server bij het booten, en toch heb je beschikking over een groot deel van de features die een RDBMS biedt. Dat is uiteindelijk het fundamentele voordeel van SQLite.

Dat leek mij ook. Dat is de primaire usecase voor dergelijke oplossingen. Ikzelf gebruik het in standalone apps of bij geautomatiseerd testen. Het snelheidsargument heb ik nog niet eerder gehoord..

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

DRAFTER86

Grappig, ik ben de laatste dagen over exact hetzelfde aan het peinzen.
Mijn plan is vooralsnog om de daemon in Python op te zetten, deze communiceert met de microcontroller via een seriële poort en luistert op een socket naar inkomende (waarschijnlijk JSON) messages, en kan daarop dus ook direct respons teruggeven of iets gelukt is of niet (Wat met pollen niet kan).
De JSON messages kunnen in theorie overal vandaan komen (webinterface, smartphone, crondaemon).
Verder zit alle logica ook in deze python daemon (events, actions, timers etc).
De webinterface dient dus enkel om status info weer te geven en bepaalde acties van de daemon te vragen.
Volgens mij is dat de netste oplossing, zodra je meer logica naar je webinterface wil transferen loop je altijd tegen het probleem aan dat het geen daemon is en je dus voor dingen als timers en interrupts weer trucs moet gaan uithalen...
Ben benieuwd wat de ideeën hier over zijn!

Edit:
Nog een kleine toevoeging, waar ik nog niet helemaal uit ben is in hoeverre de daemon multithreaded dient te zijn. Wat doe je als je tegelijk een sensor-reading van je microcontroller en een JSON request van je webinterface binnenkrijgt? Volgens mij maakt multithreading de boel alleen maar nodeloos ingewikkeld maar ik heb nog niet helemaal helder hoe je dan bijv. simultaan naar een seriële poort en naar een netwerk socket luistert...

[ Voor 19% gewijzigd door DRAFTER86 op 27-11-2013 17:37 ]

woensdag 27 november 2013 17:49

Acties:

woensdag 27 november 2013 18:04

I doubt, therefore I might be

Janoz schreef op dinsdag 26 november 2013 @ 20:29:
[...]

Maar het grootste probleem is dat je het daadwerkelijke probleem niet oplost. Het hele aansturen is zo snel als de poll interval. Zet je die op een tiende van een seconden dan reageert het systeem merkbaar traag, maar ondertussen wordt er bijna een miljoen keer een poll query op de database gedaan voor die paar keer dat het licht aan of uit gaat. Dan kun je die query gaan optimaliseren, maar ik hoop dat je zelf ook inziet dat het misschien handiger is om de wijzigingen de pushen naar het C programma.

Eigenlijk zijn alle in dit topic genoemde overige oplossingen polling:

Named Pipe, Sockets -> stream_select polling
Message queue (SYSV) -> msg_receive() polling

Mijn inziens is het van belang hoe "zwaar" deze poll is. De reden dat ik Sqlite heb genoemd als mogelijke kandidaat is dat ik uit ervaring weet dat de polling voor de toepassing van de TS licht genoeg is. Het biedt in feite flexibele ACID toegang op een stukje shared memory.

Echt event based pushen zonder polling kan volgens mij alleen met IRQ's, maar correct me if I'm wrong.

Klik hier om mij een DM te sturen • 3245 WP op ZW

Acties:

Soultaker

Je kunt natuurlijk ook via inotify o.i.d. wachten op database changes, als je principieel of praktisch bezwaar hebt tegen periodiek pollen. Helaas niet portable, maar waarschijnlijk is die low-level service dat toch al niet.

woensdag 27 november 2013 19:16

Acties:

woensdag 27 november 2013 19:53

Moderator Devschuur®

!litemod

Als je C programma gewoon een serversocket heeft kan php daar gewoon mee connecten op de momenten dat php dat nodig acht. Een queue is geen polling, maar (kan) gewoon blocken tot er wat binnenkomt. En desnoods laat je php gewoon het programma zelf starten.

Er zijn legio mogelijkheden zonder polling waarbij gewoon het php script de initiator is van het proces.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

donderdag 28 november 2013 12:06

Je maakt alleen de opzet wel gecompliceerder, want plots moet je sockets gaan onderhouden, rekening houden met communicatiefouten disconnects en weet ik wat meer. Zoal PoP al zei, meer points of failure.

Echt event based pushen zonder polling kan volgens mij alleen met IRQ's, maar correct me if I'm wrong.

Er zit natuurlijk wel een (perfomance)verschil in blocken op een select call ( is pollen ) en een periodieke query/response doen op je database ( is ook pollen )

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

Acties:

epic007

Ik weet niet hoe ingewikkeld je domotica is en hoe ingewikkeld de json berichten zullen zijn maar is het niet mogelijk een simpele http server in je daemon te bouwen?
Als je alleen maar zaken in en uitschakelt hoef je alleen maar simpele requests te doen:

http://deamon.ip.adres/getSchakelaar?id=koffiezetapparaat
http://deamon.ip.adres/se...ffiezetapparaat&value=uit

donderdag 28 november 2013 14:23

Acties:

__fred__

DRAFTER86 schreef op woensdag 27 november 2013 @ 17:31:
Edit:
Nog een kleine toevoeging, waar ik nog niet helemaal uit ben is in hoeverre de daemon multithreaded dient te zijn. Wat doe je als je tegelijk een sensor-reading van je microcontroller en een JSON request van je webinterface binnenkrijgt? Volgens mij maakt multithreading de boel alleen maar nodeloos ingewikkeld maar ik heb nog niet helemaal helder hoe je dan bijv. simultaan naar een seriële poort en naar een netwerk socket luistert...

Multi-threading is leuk, maar geen vereiste. In de hardware zit een buffer, in de driver wellicht een buffer en wie weet in je library ook nog. Zeker de hardware buffer wordt gewoon gevuld en de driver trekt die echt wel voor je leeg naar zijn eigen buffer op een interrupt.
Op een 9600 baud serieel lijntje met nauwelijks domotica verkeer kun je met die buffers een behoorlijke tijd mee voordat je die eens leeg moet trekken.

Het enige dat je dient te voorkomen is dat je blocking reads gebruikt, want dan blokkeer je je (enige) thread om te wachten op data. Dat is niet handig.

donderdag 28 november 2013 16:38

Acties: