Entwicklerschnittstelle

Die Zukunft von MWconn: Vorschläge, Ankündigungen, Diskussionen...
Antworten
ManniAT
Beiträge: 5
Registriert: Di 30. Jun 2009, 12:27

Entwicklerschnittstelle

Beitrag von ManniAT » Di 30. Jun 2009, 13:46

Hallo,

erst einmal Gratulation - MWconn ist wirklich eine super Sache.
Wir entwickeln aktuell eine verteilte Anwendung. Die (MWconn spezifischen) Anforderungen:
a.) Die "Aussenstelle" muss sich bei bestimmten Vorgängen (Ereignis, Zeit) in der Zentrale melden
b.) Die "Zentrale" muss jederzeit in der Lage sein, eine "Aussenstelle" anzufragen
c.) Das System muss sowohl mit fixer Internetverbindung (kein Problem) als auch mit "temprärer" bzw. Dialup-Verbindung laufen
d.) Die "Aussenstellen" müssen "leistbar" bleiben.

Der erste Gedanke war ein intelligentes "Serielles Modem".
So Dinger gibt's - kosten richtig Geld und können dann
a.) Zeitgesteuert
b.) Ereignisgesteuert (es ist was passiert bzw. es ist lange nix passiert)
c.) Gepollt (SMS bzw. call)
die Verbindung aufbauen.

Wenn ich von "richtig Geld" rede, dann meine ich um die 800 Teuros rum.
Dafür gibt's aber auch 2 Barebones - bzw. ich krieg um den halben Preis einen Barebone.
Auf / mit dem kann ich dann machen was ich will - bin also weit flexibler :)

Nun zum Kern der Sache. Ich habe Dein Teil gestern irgendwie beim rumsuchen gefunden, habs mir runtergeladen und installiert.
HUAWEI E220 - und das Dashboard des Providers haten PC UI Treiber nicht installiert.
Damit gings dann "nur halb" (SMS Empfang ging - aber Verbindung war keine möglich weil das Modem ja belegt war).
Dank der (deiner) super Doku war der Fehler gleich lokalisiert.
Neues Dashboard gezogen - kurz ruminstalliert - PC UI wurde installiert - und MWconn machte sofort was es sollte -- WAR NUR BEGEISTERT!!!

Die Fileschnittstelle wäre eine Option für unsere Anwendung - ABER es ist einfach schöner, wenn man direkt (aus der eigenen Applikation) mit dem Teil reden kann.
In der Doku habe ich dann die Geschichte mit dem Shared Memory gefunden.
Folgende Sachen sind mir aufgefallen:
Die Schnittstelle (um Infos zu bekommen) ist für reines Polling (Beispiel mit Timer) ausgelegt.
Weiters geht versucht das Beispiel WRITE Access zu bekommen - wenn das nicht geht wird READ Access versucht.
Ich gehe mal leise davon aus, dass der WRITE Zugriff immer dann nicht geht, wenn MWconn gerade im Memory rumschreibt.
Was mir hier fehlt ist irgendeine Synchronisation (Mutex, Semaphore, Event oder so).
Gibt es so was nicht? Oder wird es nur im Beispiel nicht erwähnt?

Mein Wunsch / Vorschlag - wie wäre es mit Message Kommunikation?
Ein üblicher Pattern dazu ist REGISTER / WM_COPYDATA.
Mal kurz erklärt:
Der "Server" (MWconn) registriert zwei Messages (RegisterWindowsMessage) und hört eine davon dann ab.
--ich nenne die mal MSG_REGISTER_CLIENT und MSG_NOTIFY_CLIENT
Der Client (also z.B. meine Anwendung) registriert die selben Messages.
Bei Start postet der Client dann MSG_REGISTER_CLIENT mit seinem WindowHandle als Parameter. Als zweiter Parameter dann noch, WAS den Client interessiert (optional) - MWconn merkt sich den Handle und reagiert mit MSG_NOTIY_CLIENT und dem Fensterhandle sowie "OK" (irgend ein nummerischer Wert halt) als Ergebnis.
Wenn WMconn was neues hat (aktuell wird process_counter inkrementiert) sendet es eine WM_COPYDATA Nachricht an die registrierten Clients.
Dabei wird einfach der "hintere Teil" (ohne Command) der aktuellen Struktur an den Client übergeben.

Wenn der Client was von MWconn will geht er den selben Weg - er sendet WM_COPYDATA mit dem Command als Daten.
MWconn kann sofort (return value) OK oder "falsches Command" melden.

Der Vorteil so einer Implementierung:
a.) Message driven -- nicht sinnlos rumpollen, wenn eh grad nix los ist
b.) Kein manuelles Synchronisieren (der oben erwähnte nicht gefundene Mutex :)) nötig
c.) Super erweiterbar um z.B. eine "SMS Erhalten" "Verbindung hergestellt" usw. Info an den Client zu senden.
d.) Auch leicht erweiterbar im Sinne von "neue Funktionalität".
-- hier fällt mir das eine "Missing Feature" ein - SMS Senden via "API" (habe in den Commands beim Beispiel nix dafür gefunden).

CONCLUSIO (ich weiß, dass ich ein Vielschreiber bin :)):
a.) Gibt es bei der aktuellen Shared Memory Implementation einen Synchronisierungsmechanismus (Mutex, Semaphore, Event)?
b.) Vorschlag / Wunsch: statt (zusätzlich zu) Shared Memory eine Message orientierte Kommunikation ermöglichen
c.) Wunsch: SMS Senden via API (u.U. habe ich da was übersehen)

Nochmal Gratulation zu der wirklich gelungenen Software

lg

Manfred

Opilionn
Administrator
Beiträge: 719
Registriert: Sa 26. Jul 2008, 18:25

Re: Entwicklerschnittstelle

Beitrag von Opilionn » Di 30. Jun 2009, 18:24

Hallo & danke für die ausführlichen Beschreibungen und Ideen!

MWconn besitzt derzeit wirklich nur diese "billige" Shared-Memory-Schnittstelle. Das hat zwei Gründe:
1. Sie war sehr einfach zu realisieren.
2. Es können mehrere Programme gleichzeitig drauf zugreifen und die Infos lesen.

Manches Clientprogramm interessiert sich nur für die Signalstärke, ein anderes für die Betriebsart oder für die Statistik. Wenns danach geht, müsste man also einen parametrierbaren Eventmechanismus bauen, denn alle diese Infos ändern sich schrittweise und nicht alle gleichzeitig.
Natürlich braucht Polling mehr Zeit und es gibt immer eine kleine Verzögerung bei der Datenübernahme, aber die Nachteile sind wirklich minimal. Letztlich ist es nur ein einfacher Hauptspeicherzugriff und der ist wirklich super schnell.

Write-Access ist ohne Weiteres möglich, wird aber von Windows (Vista) geblockt, wenn der Security Descriptor des Shared Memory nicht entsprechend eingestellt ist. Das heißt, MWconn muss entsprechend konfiguriert werden: Parameter "IPC=" in MWconn.ini. Einfach im PDF danach suchen.

Wenn ich es richtig verstehe, geht es dir in erster Linie um die SMS-Kommunikation.
Hierfür gibt es einen Event-Mechanismus auf die ganz herkömmliche Art per Programmaufruf. Schau einfach in CONFIG.exe auf die Registerkarte "Extern".
Für den Versand von SMS reicht es, die zu sendende SMS in den Ordner sms_send zu kopieren. Das Format ist in Kapitel 14 (PDF) beschrieben.

Der Umweg über das Dateisystem ist gewollt. Falls das Programm abstürzt oder der Rechner zur Unzeit neu gestartet wird, bleibt die SMS-Datei erhalten. Auch die Protokollierung der gesendeten SMS besteht dann aus einem einfachen Verschieben von sms_send nach sms_out.

Sorry, dass das alles wie ein "ja, aber" klingt... ;-)
Vielleicht hab ich auch etwas übersehen.

Grüße aus der Bastelstube
Opilionn

ManniAT
Beiträge: 5
Registriert: Di 30. Jun 2009, 12:27

Re: Entwicklerschnittstelle

Beitrag von ManniAT » Di 30. Jun 2009, 19:04

Hi Opilionn,

keine Angst, es klingt nicht wirklich nach "ja aber" - ich kann die Gründe für das Verwenden von Shared Memory verstehen.
Das mit "möglicherweise verweigertem Write Access" habe ich einfach aus deinem Quelltext gelesen - und dabei nicht an Vista gedacht :)
Filesystem für SMS ist auch sinnvoll.

Ich wäre nicht ich, wenn ich nicht irgendeinen Punkt finden würde wo ich mosern kann:
Shared Memory ist etwas mehr als "geteilter Hauptspeicherzugriff" - hier passiert allerhand - prüfen von Security, mappen des "fremden" Speichers in den eigenen Adressraum...
:)

Spass beiseite - du hast natürlich recht, dass so ein Messaging Klaperatismus einiges an Aufwand darstellt.
Vor allem müsste man (wie du ja anmerkst) um es "richtig" zu machen dann auch "Eventselektionsmechanismen" einführen.

Sollte aber kein Thema sein - ich werde einfach einen "Wrapper" schreiben - also so ein C++ Teilchen, das eine Thread startet, der am SM rumpollt und im Fall des Falles Messages versendet.
Oder ich nehme gleich C# - der Interop sollte nicht zu schwer sein.
Das hat sogar noch den Vorteil, dass ich gleich .NET zum Messaging verwenden kann.
Also entweder in meine App einbinden - oder eigenständig laufen lassen und nen WCF Service über named pipes anbieten.

Bevor jetzt freundlich Hinweise kommen - ich habe hier http://www.mwconn.info/viewtopic.php?f=9&t=200 gesehen, dass Nelix (und cware) da was gebastelt haben.
Allerdings scheint das (laut den letzten Posts) noch nicht ganz rund zu laufen.
Zudem möchte ich (wenn ich es denn wirklich mache) gleich nativ mit Interop an die Sache herangehen.

Danke für deine ausführliche Antwort und lg

Manfred

Opilionn
Administrator
Beiträge: 719
Registriert: Sa 26. Jul 2008, 18:25

Re: Entwicklerschnittstelle

Beitrag von Opilionn » Di 30. Jun 2009, 20:22

Hmmm... nur damit ich das doch noch begreife... :-)
Um welche Events gehts dir? "SMS wurde empfangen"? "Signalstärke hat sich geändert"? "Funkzelle hat gewechselt"? ...

ManniAT
Beiträge: 5
Registriert: Di 30. Jun 2009, 12:27

Re: Entwicklerschnittstelle

Beitrag von ManniAT » Di 30. Jun 2009, 21:13

Jep,

das ist es + Verbindung wurde hergestellt / getrennt, SMS wurde gesendet (noch k.A. wie ich das ermittle).
Verbindung ist möglich, (oder auch nicht) usw.
EDIT - ich gestehe offen - mich interessieren nur rudimentäre Dinge (Speed, Zelle, usw. sind mir wurst - da vertrau ich auf deine Software - die handelt das schon :)

Und natürlich auch der umgekehrte Weg - also aus .NET ganz simpel:
MWconnNet.SendCommand(.....);

Um das gleich mal klarzustellen - deine Software kann das alles auf dem einen oder anderen Weg.
Ich mag es halt einfach, wenn ich die Dinge aus meinen .NET Anwendungen ohne großen Umweg bzw. mittels "einheilticher Schnittstelle" erreiche. Und ob ich jetzt eine Funktion schreibe, die ein File produziert - oder gleich via Shared Memory das Command absetze bleibt sich gleich.
Last not least - wie ermittle ich denn am einfachsten das Programmverzeichnis von MWconn - ich glaube mittels SM "MWCONN_PATH" :)

Wobei - ich weiß gehort wo anders hin ich da gleich eine Frage habe.
Wenn ich MWconn mit mehreren Karten betreibe - wie erreiche ich dann das Shared Memory?
Nummerierst du da durch so nach dem Motto: Gloabl\MWCONN_IO und dann Global\MWCONN_IO2...?

lg

Manfred

ManniAT
Beiträge: 5
Registriert: Di 30. Jun 2009, 12:27

Re: Entwicklerschnittstelle

Beitrag von ManniAT » Di 30. Jun 2009, 21:18

Ach ja,

ich blogge gerade ein wenig über das Projekt - hier kannst du sehen um was es geht:
http://manni-at.spaces.live.com/blog/cn ... !190.entry

Opilionn
Administrator
Beiträge: 719
Registriert: Sa 26. Jul 2008, 18:25

Re: Entwicklerschnittstelle

Beitrag von Opilionn » Di 30. Jun 2009, 21:44

Ah, danke. Bevor ich mir das Blog anschaue, kurz die Antworten:
1. Ja, MWCONN_PATH. :-)
2. Du kannst mehrere Instanzen von MWconn laufen lassen. Aufrufparameter: INSTANCE=name
Der angegebene Name wird dann an alle benutzten Semaphoren und an den Namen des Shared Memory angehängt.

cware
Beiträge: 128
Registriert: Mo 4. Aug 2008, 19:42

Re: Entwicklerschnittstelle

Beitrag von cware » Fr 3. Jul 2009, 20:13

@ManniAT: Wenn du C# einsetzt, kannst du dir ja direkt einmal das Projekt MW.net von einem unserer User ansehen... evtl. kannst du Ihm bei seinem Wrapper ein wenig unter die Arme greifen...


cheers...

ManniAT
Beiträge: 5
Registriert: Di 30. Jun 2009, 12:27

Re: Entwicklerschnittstelle

Beitrag von ManniAT » Fr 3. Jul 2009, 20:27

Jo cware,

wenn ich das angehe (z.Zt. haben ein paar andere Dinge Priorität) werde ich einen nativen Wrapper um das VM schreiben.
Also das ganze direkt mit Interop abhandeln.
Ich habe mir mal (halbwegs heftig) die Nächte um die Ohren geschlagen beim Versuch eine "pas lib" zu wrappen.
Das Ergebnis (div. Probs mit Multithreading und Memory Management) - ich habs nativ gemacht - und passt :)
Dazu die Story: http://forum.velleman.be/viewtopic.php?f=3&t=2247

Aber eines ist klar - wenn ich das Ding mache wird es hier gepostet - eh logisch.

lg

Manfre

Antworten