suche Lösungsansatz für Situation? Ist Com möglich?

[Kedariodakon]

Nun bin ich gerade über einige Sachen bei meinen Recherchen gestolpert und hab dazu mal eine Frage...
Com Ist eine feine Sache, wie ich gerade festgestellt habe, nur ist die Frage ob das, was ich realisieren möchte damit machbar ist.

Folgende Situation:

• Ich hab ein Gerät, welches über eine Schnittstelle angesprochen wird.
• Diese Schnittstelle gilt Systemweit (Also einmalig am Rechner), da Gerät am Com-Port angeschlossen.
• Der Rechner ist ein Windows Terminal-Server
• Ich hab mehre Anwendungen welche diese Schnittstelle implementieren und verwenden.
• Nur eine Anwendung kann zur gleichen Zeit die Schnittstelle verwenden! (Andere Anwendungen müssen warten bis die Schnittstelle vom aktiven Prozess beendet wurde, um sie öffnen zu können.)

Zur Zeit sieht das so aus, dass Anwendungen von Hand beendet werden müssen, damit eine andere Anwendung die Schnittstelle verwenden kann.
Problem der Situation dabei:

• Die Anwendungen müssen nicht unbedingt in der selben Session laufen, sprich Benutzer A hat die Anwendung offen, Benutzer B möchte sie öffnen, kann es aber nicht!
• Benutzer B ist kein Admin, sieht also auch nicht die Prozesse der anderen Benutzer, deshalb weiß er auch nicht (Angenommen er kennt alle Anwendungsnamen) Wer/Was die Schnittstelle belegt...

(Vereinfacht) Ziel ist es nun, dass ein Anwender sieht, welche Anwendung unter welchen Benutzer die Schnittstelle belegt und der Schritt weiter, die Schnittstelle eines anderen beenden/pausieren kann.
Ganz so einfach ist die Sache dann aber wieder nicht, denn wie ihr euch das denken könnt, ist bei solchen Sachen eine Rechte-Verwaltung zwingend notwendig!

Nun will ich den vereinfachten Schritt ein wenig komplexer gestalten, und die Schnittstelle aus den vorhanden Anwendungen entfernen und als System-Dienst laufen lassen.
Anwendungen die diese Schnittstelle nun verwenden wollen, bekommen nun ein Zugang zur Schnittstelle vom Dienst gestellt, welche der Dienst pausieren, entziehen und erneut zustellen kann.

Grund ist ganz simpel, die Rechteverwaltung sollte vom Benutzer selbst nicht zugänglich sein, sprich der Dienst regelt die Zugänge, und stellt nötige Informationen zur Verfügung (z.b. Welcher Benutzer verwendet die Schnittstelle., welche Anwendunge verwendet er dafür)

Nun hab ich solche Sachen bis jetzt noch nie mit Delphi umgesetzt, daher suche ich nach geeigneten Möglichkeiten die Sache umzusetzen.

Die Schnittstelle an sich ist zur Zeit als Interface gelöst, da die Schnittstelle nicht unbedingt mit einem Gerät am Com-Port komunizieren muß.
Von mir angedacht war, dass der Dienst solange er läuft eine Com-Object registriert, welches sich die Benutzer abhollen können.
Dieses Object (Schnittstelle) stellt die Kommunikation zu der eigentlichen Schnittstelle im Dienst her und stellt Möglichkeiten bereit Informationen auszutauschen.

Nun ist die frage ob dies nun so mit COM zu lösen ist, oder ein andere Ansatzpunkt gefunden werden muß.
ausgeschlossen hab ich:

• Messages
• Socketverbindungen
• Mailslots & Named Pipes

Meine Gründe: Für diese Sachen müßte noch ein komplexes Kommunikations-Protokoll erstellt werden, welches ich vermeiden möchte.
Zudem ist sicher, dass die Anwendungen nur auf den Rechner laufen, sprich eine Netz-Kommunikation ist nicht notwendig, daher muss die Lösung auch nicht Plattform unabhängig sein.


Bye Christian

[oki]

Hi,
also ich weis nicht wer dir da helfen kann, aber für mich ist das estwas nebulös. Ich habe folgendes verstanden:

Du möchtest einen "Server" schreiben, der den Exclusivzugriff auf eine Schnittstelle für mehrere Clients managed. Jeder Benutzer (Client) soll sehen wer noch connected ist und sich mit Priorität an die zu händelnde Schnittstelle verbinden können.

Ich versteh den Sinn nicht ganz und wie das funzen soll (praktisch) wenn jeder Nutzer wahrlos andere Nutzer von einer schnittstelle trennen kann.

Grundsätzlich sehe ich hier aber eine Server-Client-Funktionalität.
COM ist hier sicher eine Möglichkeit, aber auch nicht ohne. Hab da leider nicht so viel Erfahrung. wenn es keine Sockets sein sollen, die dir im Bereich der Kommunikation ja schon Server-Client-funktionalität liefern, dann ist COM sicher ein weg.

Gruß oki

[Kedariodakon]

Ja so in etwa ;)

Also die Hauptanwendung die läuft ist ein Importer welcher über die Schnittstelle Daten importiert, dieser hat natürlich die höchste Prio und darf nur von gewählten Personen gestopt werden...

Dann gibts Konfigurationsanwendungen die auch den Importer stoppen/pausieren müssen um mit den Geräten, welche hinter der Schnittstelle stehen Konfigurationen/Anpassungen durchzuführen, dies durfen noch weniger Leute als den Importer Stopen, ihnen darf auch die Schnittstelle nicht entzogen werden...

Dann gibts noch ein Monitor Programm, welches neben dem Importer laufen kann, also die können parallel auf die Schnittstelle zugreifen, also eigentlich zwischen den Anfragen des Importers (da seriell)...

Damals war das mal alles ein Programm, dies wurde in handliche kleine aufgeteilt, womit meherere Benutzer arbeiten können, aber denoch immer einer, oder im selben Acc.

Ist auch nicht so das jetzt alle Anwendungen rund um die Uhr laufen, mal die mal die mal die, nur dann vergisst wieder wer eines der Programme in seiner Session zu schließen und eine kritische Anwendung kann nicht gestartet werden...

Hab nun schon ein wenig mit COM herrumgespielt, aber ich bekomme einfach keine Sessionübergreifenden Objecte hin...
Daher auch die Frage ob sowas überhaupt geht und wenn, wie?

Bye Christian

[Reinhard Kern]

Hallo,

das lässt sich meiner Ansicht nach wesentlich einfacher lösen (mit Ausnahme der echten Konflikte, die softtwaremässig garnicht lösbar sind):

Ich kann an einen PC bis zu 64 meiner Analyse-Geräte anschliessen, neben Comx auch Ethernet oder USB, hier interessieren nur die Geräte, die über eine Com-Schnittstelle angeschlossen sind. Diese haben die Nummer des Comports in Ihrer Konfiguration eingetragen. Hat ein Gerät COM5 und soll aktiviert werden, so fordert die Log-Software COM5 von einem Pool von derzeit 16 Com-Schnittstellen an (u.a. weil es 64 Geräte geben kann, aber niemals so viele Comports, die würden über LWL-Multiplexer angeschlossen). Wird COM5 bereits von einem anderen Gerät benutzt (Multiplexer), so stellt der Pool sofort ein Handle zur Verfügung, andernfalls initialisiert er erst eine neue Schnittstellendatei COM5.

Ein Gerät kann inaktiv sein, dann beachtet es die Logsoftware nicht, oder aktiv, dann versucht die Logsoftware, über sein Comport Verbindung aufzunehmen - klappt das nach einiger Zeit nicht, oder es kommen eine bestimmte Anzahl von Fehlern nacheinander, wird das Gerät auf inaktiv zurückgestuft. Steht die Verbindung, so kann ein Experiment gestartet werden. Bei laufendem Experiment wird die Verbindung nur auf Befehl deaktiviert oder nach endgültigem Zusammenbruch der Übertragung. Übrigens kann die Verbindung zu einem laufenden Experiment jederzeit wieder aufgenommen werden, solange das Gerät noch läuft.

Der Pool prüft, ob ein Comport seit einiger Zeit nicht mehr angefordert wurde, ist das der Fall, wird COMx geschlossen und damit ans Betriebssystem als verfügbar zurückgegeben. M.a.W. nicht benutzte Comports (von deaktivierten Stationen) sind automatisch wieder frei verfügbar, läuft dagegen ein Experiment, so kann der Comport solange nicht anderweitig benutzt werden (privilegierter Status).

Aus der Logsoftware heraus können natürlich alle Verbindungen deaktiviert werden, am einfachsten dadurch, dass man sie beendet. Die Geräte sind autark und speichern ihre Daten intern, man kann also auch die Logsoftware beenden und mit den Comports machen was man will, wenn man die Logsoftware einen Tag später wieder startet, holt sie sich die Daten von den laufenden Experimenten ab als ob nichts gewesen wäre. Das Konzept erlaubt es sogar, ein Experiment auf einem Gerät von 2 PCs in USA und Europa parallel zu überwachen.

Gruss Reinhard

[Kedariodakon]

Ich versteh jetzt nuich worauf du ganz hinaus willst, ich hab ein Gerät an einem Comport.

Soweit ich das verstanden hab ist deine Lösung Hardwaremäßig oder? Oder ist das eine Software die virtuelle Comports erzeugt?

Bye Christian

[Reinhard Kern]

Zitat:

Zitat von Kedariodakon

Ich versteh jetzt nuich worauf du ganz hinaus willst, ich hab ein Gerät an einem Comport.

Soweit ich das verstanden hab ist deine Lösung Hardwaremäßig oder? Oder ist das eine Software die virtuelle Comports erzeugt?

Bye Christian

Missverständnis: es ist völlig egal, ob ein Comport physikalisch vorhanden oder von einem Treiber virtuell erzeugt ist.

Vergiss meine ganze Beschreibung bis auf den Rat, das Comport wann immer möglich freiwillig zu schliessen. Du kannst z.B. beim Konfigurationsprogramm das Port nur auf den Knopf "Übernehmen" öffnen, konfigurieren und wieder schliessen, konsequent durchgeführt löst sich ein grosser Teil des Problems in Luft auf. Wenn dann noch 2 Programme das Port gleichzeitig exklusiv benötigen, ist das ein Fehler im Systemkonzept.

Eine Client-Server-Struktur mit Rechteverwaltung für 1 Port mit 1 Gerät ist für mich Overkill mangels besserer Ideen. Und so wie du das konzipiert hast, müsste ja im Notfall immer ein Admin zum Freischalten bereitstehen - willst du für dein Gerät einen 24-Stunden Rechenzentrumsbetrieb einführen?

Gruss Reinhard