mikrocontroller.net

Forum: PC-Programmierung Interprozesskommunikation


Autor: chaqy Bruno (bigchaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo zusammen,
ich hoffe dass ich im richtigen Forum bin ;)
In meinem Projekt,soll ich die Kommunikation zwischen eine
3d Robotersimulation mit einer SPS über Bussytem-IO realisieren.
Die Simulation besteht aus verschiedene Motoren und Sensoren, die analog 
zu den realen Geräten über Eingäng und Ausgäng verfügen.
Da die Robotersimulation auf c# basis laüft,habe ich an .COM gedacht, um 
die Kommunikatin zwischen den Softwarekomponenten (Motoren,Sensoren)und 
den Ports "Interprozesskommunikation".
Meine Kentnisse in .COM ist sehr bescheiden,deswegen würde ich gern mal 
paar fragen stellen:
-ist .COM das richtige dafür?
-ist dieser Lösungsweg überhaupt möglich?
-oder hat jemand einen besseren Vorschlag?
ich bedanke mich im voraus.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mehrere Programme unter Windows könnten auf unterschiedlichste Weisen 
kommunizieren. Wenn sie alle auf einem Rechner laufen, gibt es unter 
anderem folgende Mechanismen:

- Windows-Nachrichten
- Named Pipes
- COM
- Sockets
- Shared Memory mit Mutexen zur Synchronisation

Netzwerkübergreifend gehen

- Named Pipes
- DCOM ("distributed COM")
- Sockets

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SHM artet oft in äußerst hässliches Herumgesperre mit Mutexen/Semaphoren 
aus, ist eher etwas, um schnell große Datenberge umherzuschaufeln.

(Benannte) Umleitungen sind eine wundervolle Sache, wenn man die 
Anwendungskomponenten nachher einfach zusammenstöpseln möchte, quasi ein 
Quellen-Senken-Konzept. Sofern man die benannten Umleitungen im 
Dateisystem verankern kann ('FIFO'), so bietet sich die Benutzung von 
Standardein- und Ausgabe an, und zwar mit einem einfachen 
Klartextprotokoll. Dann kann man prima debuggen und auch von Hand 
interagieren.

Schließlich könntest du echte Sockets benutzen. Sollte dann aus 
irgendwelchen Gründen ein Teil der Anwendung umziehen müssen, etwa auf 
ein Embedded-Linux-System, hast du leichtes Spiel.

Ansonsten würde ich ganz stark die Finger von COM, DCOM, ActiveX, DDE 
und all diesen Versuchsballons lassen...
Schau mal in 'The Art Of UNIX Programming' hinein, da ist ein ganzes 
Kapitel über die vielfältigen IPC-Mechanismen unter UNIX geschrieben. 
Vieles geht sicherlich nicht direkt unter Windows, aber um mal zu 
überfliegen, was wozu geeignet ist, taugts allemal.

Autor: Raik C. (raik_c)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> (Benannte) Umleitungen

Ist das die offizielle Bezeichnung für "named pipe"? Ich nutze die 
Dinger seit bald 18 Jahren, aber dieser "Übersetzung" bin ich noch nicht 
begegnet.

Das ist ja noch schlimmer als die "serielle Zeigereinheit", mit der IBM 
uns beglücken musste.

Named Pipes bieten Sockets gegenüber den Vorzug, daß sie mit Paketen 
arbeiten können, werden am einen Ende der Pipe nacheinander vier 
Schreibvorgänge mit 1000, 750, 1200 und 900 Byte durchgeführt, kommen am 
anderen Ende auch vier einzelne Pakete dieser Größen an, die mit 
entsprechenden Lesezugriffen auch einfach aus der Pipe 'rauszuholen 
sind.
Bei Sockets muss aufgrund der streamorientierten Architektur anders 
vorgegangen werden, das aber ist je nach Anwendung kein Problem.

Ein Server kann auch mehrere Instanzen gleichzeitig zur Verfügung 
stellen, was auf den ersten Blick für größere verteilte Systeme sehr 
praktisch erscheint. Die Erfahrung allerdings zeigt, daß MS den Gebrauch 
von "named pipes" nicht übermäßig unterstützt, mit jeder neueren 
Windowsversion schwindet die Anzahl simultan nutzbarer "named pipes" pro 
Rechner, was nirgends dokumentiert ist.

Für Neudesigns halte ich Sockets für eine sinnvollere Lösung, allein 
schon aus Gründen der Portabilität auf andere Systeme.

Autor: chaqy Bruno (bigchaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zuerst möchte ich mich für eure Antworten bedanken.
Was Betriebsysteme angeht,kenne ich mich nur mit Windows einbisschen 
aus,also UNIX kommt aufkeinen fall in Frage,deswegen würde ich gern in 
Windows bleiben,und mich mit COM auseinandersetzen.
Ich war bei meiner Suche nach".COM" leider einbisschen verwirrt,denn 
meistens kommt Begriff ".NET" raus. Ich weiss mittlerweile, dass ".NET" 
die Erweiterung von ".COM" ist,allerdings weiss ich nicht in wie fern.
Ist ".Net" eher für die Erstellung von Webapplikationen gedacht?

Autor: Raik C. (raik_c)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin,

ich ziehe meine Link's zurück. Ich dachte Du bist ein wenig vertraut mit 
c#

Raik

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast da ein sehr tiefgreifendes Verständnisproblem, würde ich meinen.

COM zieht einen immensen Wasserkopf hinterher, deshalb mein Abraten 
davon. Dagegen setzt du mit knapp einem halben Dutzend Funktionen schon 
eine Socketverbindung auf.

Rufus: Keine Ahnung. Ich kenne die Pipe als eine Form der Umleitung, da 
liegt es für mein Empfinden nahe, von benannten und anonymen Umleitungen 
zu sprechen. Mag aber eine eigene Wortschöpfung sein :-)
Und ja, IBM hatte einen fürchterlich gruseligen Wortschatz. Heute 
kümmert sich Microsoft darum, mit der Datenausführungsverhinderung zum 
Beispiel...

Müsste mal im K&R nachschauen, der ist hervorragend übersetzt, mit viel 
Feingefühl, bei der Übersetzung von Fachbegriffen sinnvolle deutsche 
Worte zu prägen.

Autor: chaqy Bruno (bigchaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ haku.
dann würdest du bitte mich besser aufklären.ich setzet mich zum ersten 
mal damit auseinander.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> Named Pipes bieten Sockets gegenüber den Vorzug, daß sie mit Paketen
> arbeiten können, werden am einen Ende der Pipe nacheinander vier
> Schreibvorgänge mit 1000, 750, 1200 und 900 Byte durchgeführt, kommen am
> anderen Ende auch vier einzelne Pakete dieser Größen an, die mit
> entsprechenden Lesezugriffen auch einfach aus der Pipe 'rauszuholen
> sind.

Das kann man doch bei Sockets auch.

> Bei Sockets muss aufgrund der streamorientierten Architektur anders
> vorgegangen werden, das aber ist je nach Anwendung kein Problem.

Nur wenn man Stream-Sockes benutzt.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, .Net ist nicht die Erweiterung von COM (ohne Punkt). COM ("Common 
Object Model") ist eine Technik, die es ermöglicht, Programme aus 
einzelnen Komponenten zusammenzusetzen und dabei eine standardisierte 
Art von Schnittstellen zwischen diesen Komponenten verwendet. Vorläufer 
davon waren OLE und ActiveX. Über COM werden unter Windows auch ganze 
Programme (fern)gesteuert, das nennt sich dann Automation und 
funktioniert z.B. mit Excel und Co.

Nachfolger von COM sind COM+ bzw. DCOM, letzteres ermöglicht auch den 
netzwerkübergreifenden Zugriff auf Komponenten. DCOM ist die Grundlage 
des in der Automatisierungstechnik verwendeten herstellerübergreifenden 
Kommunikaitionsprotokolls OPC ("open process control").

.Net ist eine Laufzeitumgebung für in dafür angepassten 
Programmiersprachen (C#, VB.Net sowie die Perversion "Managed C++" bzw. 
"C++/CLI" und viele andere) geschriebene Programme, die eine sehr 
ausführliche und weitgehende Unterstützung für alle möglichen Aufgaben 
zur Verfügung stellt, und innerhalb gewisser Grenzen sogar 
plattformübergreifend verwendbar ist (unter anderen Betriebssystemen 
gibt es die .Net-Implementierung Mono).

Um COM bzw. dessen neueren Varianten zu nutzen, muss man keine 
.Net-Sprache einsetzen.

Autor: chaqy Bruno (bigchaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke für die ausführliche Erklärung.Mich haben ein paar Artikel ausm 
Internet durcheinander gebracht, in denen es stand, dass .Net die 
Erweiterung von .COM sein sollte,ich fand dafür keinen richtigen 
zusammenhang,aber wie gesagt,ich setze mich zum ersten mal damit 
auseinander.
danke noch mal.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
COM ist eher nicht ein Ansatz zur Interprozesskommunikation, eher um 
Komponenten gemeinsam zu benutzen. Die Verzahnung ist fuer 
Interprozesskommunikation viel zu hoch.
Ich wuerd auch mit Sockets arbeiten. Das laeuft auf demselben Rechner 
auf shared memory hinaus, laesst sich aber ohne Probleme auf 
verschiedenen Rechner verteilen, auch zum Debuggen.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doppel Oschi schrieb:
> Ich wuerd auch mit Sockets arbeiten. Das laeuft auf demselben Rechner
> auf shared memory hinaus, laesst sich aber ohne Probleme auf
> verschiedenen Rechner verteilen, auch zum Debuggen.

Shared memory ist schon noch was anderes. Bei Sockets müssen die Daten 
mehrfach kopiert werden, auch lokal. Und falls es sich um TCP- oder 
UDP-Sockets handelt, muß das ganze auch noch zweimal durch den IP-Stack 
durch.
Dafür ist es, wie du schon schreibst, flexibler, und die Synchronisation 
ergibt sich ganz von selbst.
Der Overhead bei den Sockets kommt auch erst zum Tragen, wenn es sich um 
richtig große Datenmengen handelt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.