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.
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
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.
moin, schau mal hier http://www.codeproject.com/KB/cs/ipc_wmcopy.aspx?msg=2218946 oder hier http://www.mycsharp.de/wbb2/search.php?searchid=196468 raik
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.
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?
moin, ich ziehe meine Link's zurück. Ich dachte Du bist ein wenig vertraut mit c# Raik
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.
@ haku. dann würdest du bitte mich besser aufklären.ich setzet mich zum ersten mal damit auseinander.
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.
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.
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.
Zurück zur Frage: http://stackoverflow.com/questions/84855/what-is-the-best-choice-for-net-inter-process-communication
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.