Socket API

Hallo !

Ich habe hier die folgende Frage zu dem Thema Socket APi und Kommunikation zwischen Prozessen vorliegen:

Kommunikation zwischen Prozessen kann durch Socket API zwar realisiert werden, aber stellt das eher die Ausnahme da? Falls ja, so begründen sie bitte.

Also erstmal ist keine Angabe darüber gemacht worden, ob es sich um eine Kommunikation im Internet handelt oder in einem Firmeninternen Netzwerk (Intranet? Hoffe die Bezeichnung passt hier nun). Also ich habe eine Lösung ausarbeiten können, aber bin mir dabei nicht wikrlich sicher. Ich glaube durch die Verwendung einer möglichen Middleware (bestehend aus Modulen der Standrads J2EE oder .Net oder auch Corba) brauche ich das Rad nicht immer wieder neu zu erfinden, sondern nutze den Vorteil des Automatismus und brauche mich als Anwendungsentwickler nicht mehr mit solche technischen Details befassen.

Grundsätzlich ist die explizite Kommunikation zwischen zwei Prozessen über Socket-API möglich, bringt aber auch einige Nachteile mit sich. Erstmal brauche ich gute Programmierkenntnisse und muss ziemlich viel beachten, bspw. die Hetrogenität der Betriebssystemen und der Hardware (unterschiedliche Darstellung der Daten im Speicher) und evtl. werden unterschiedliche Programmiersprachen verwendet. Ich muss also jeden Quark selbst programmieren. Ich glaube bei expliziter Verwendung des Socket API´s kann man nicht mehr von wirklicher Verteilungstransparent sprechen.

Vorteile wären evtl. mehr Flexibilität und individuellere Handhabung...

Also um es nun noch mal verständlich zusammenzufassen. Es findet eine Kommunikation immer über Socket API statt.

1. Entweder automatisiert und für mich als Anwendungsentwickler transparent umgesetzt durch die jeweils verwendete Middleware...

2. ...oder ich mache es selbst ohne Middleware und baue selbst über das Socket API Verbindungen auf. Mache ich es selbst, habe aber erheblichen Mehraufwand. Mich würde interessieren, ob ich so auch in Konflikt mit einigen Firewalls kommen könnte.

Ich glaube ein Webservice kommuniziert ja immer über Port 80 (http) und sind deshalb auch über Intranetgrenzen hinaus erreichbar. Der Port 80 ist ja i.d.R. bei Firewalls offen. Alle die vom Webservice geschickten Daten, Anfragen etc. werden getunnelt über diesen Port übertragen (z.B. über eine Firewall in ein Firmennetz). Nutze ich nun selbst das Socket API, müssen doch Firewalls bestimmte Ports freigeben, damit die mit mir überhaupt kommunizieren können oder? Und das würde auch die Sicherheit gefährden...

...hoffe ich bin mit meiner Antwort nicht komplett auf dem Holzweg...

Wo ist da jetzt die Frage?

(Und versuch erstmal solche schwergewichtige Middleware zu verwenden ohne wahnsinnig zu werden. Besonders wenn es nur um Sockets geht, ist das der absolute Overkill.)

Das ist die Frage:

Kommunikation zwischen Prozessen kann durch Socket API zwar realisiert werden, aber stellt das eher die Ausnahme da? Falls ja, so begründen sie bitte.

Ich wollte nur wissen, ob meine Antwort halbwegs passt

Wie können eigentlich Prozesse Daten miteinander austauschen, die auf einem gemeinsamen Rechner liegen? Also Prozesse, die nicht auf unterschiedlichen Rechner liegen und nicht über das Netz kommunizieren müssen?

Da brauche ich ja kein Socket API, geht das hier über die Text- und Datensegmente der jeweiligen Prozesse? Oder ist ein Austausch untereinander überhaupt nicht möglich?

MFG

Mit den Prozessen sind Unterprozesse des Programm auf diesem Rechner gemeint, welches mit irgend etwas anderem auf einem Server kommuniziert. Wenn du Threads (Multithreading) kennst, kannst du dir das mit den Prozessen so ähnlich vorstellen. Das Programm erzeugt Unterprozesse, die eine ganz bestimmte Aufgabe übernehmen und der Unterprozess sendet dem Programm ein Signal wenn er fertig ist. Das Programm beendet den Unterprozess (Subprozess) dann.

Da es hier um die Programmierung geht, verschiebe ich den Thread mal ins richtige Unterforum.

Wenn ich der Prof wär, der die antwort liest, würd ich durchdrehen
Wie sagte unser Prof noch immer? Wenn Sie sich nicht kurz und bündig ausdrücken können, haben Sie als Informatiker verloren

Leider hast du nicht angegeben, in welchem fach die Frage gestellt wurde und in welchem Bezug zur Realität (präzise Aufgabenstellung) sie steht.

Aus einer Vorlesung Betriebssysteme heraus würde ich deuten, dass die Frage die du beantworten sollst folgende zu sein scheint:

"Ergibt es einen Sinn Sockets zur Interprozesskommunikation zu verwenden und wenn ja, welchen?"

Antwort: Ja, es ergibt durchaus einen Sinn!

Verdeutlichung:
Welche Arten von Interprozesskommunkation kennen wir?
Nun alle möchte ich nicht aufzählen (Ich denke Pipes befehl1 | befehl 2 werden dir geläufig sein), aber da wären unter anderem noch

[*]Semaphore
[*]Shared Memory
[*]Mesasge Queues

und

[*]Sockets

http://en.wikipedia.org/wiki/Inter-process_communication

Sockets gehören zu den absolut gängigen IPC-Lösungen und werden besonders häufig von Unix-Diensten eingesetzt.

Nun die Begründung zur oben gegeben Antwort:
Sockets bieten einen großen Vorteil: sie arbeiten über Rechnergrenzen hinweg.
Das heißt Prozesse können auf verschiedenen Rechnern laufen und trotzdem zusammenarbeiten.


Dein XServer ist z.B. so ein schönes, klassisches Beispiel dafür.


Sockets sind quasi auf jedem Betriebssystem realisiert, fast jede programmiersprache bietet eine einheitliche API an um sie anzusprechen. Da du gerade von Java sprichst bekommst du sogar das absolute Killerargument für Sockets implizit mit der Sprache geliefert!
Die Java API liefert eine einheitliche Methode um Sockets anzusprechen. Um die jeweilige Implementierung musst du dich nicht kümmern, da sich die jeweilige JVM-Implementierung betriebsystemspezifisch darum kümmert.
Der Datenverkehr über Sockets in Java ist total simpel (wo braucht man da große Programmierkenntnisse). Man muss lediglich die Klassen Socket und ServerSocket kennen und Kenntnisse über IOStreams in Java haben. Das sind Grundlagen, über die Java-Entwickler verfügen sollte.


Falls die Frage anders gemeint sein sollte, bitte korrigiere mich. Wenn es darum geht, ob man evt. schon eine vorhandene Java messaging Api verwenden sollte, oder selbst eine Socket Realisierung anstreben sollte steht man natürlich vor der Fragestellung ob man das Rad neu erfindet oder die bestehende Lösungen verwendet (RMI z.B.)

Gruß
Mani

@mani: Gut zu wissen. Ich hatte es mir anders erklärt, aber man lernt ja nicht aus und so habe ich wieder was gelernt.

PS:
Nobody is perfect und das ist gut so.