Ein großer Nachteil aller bis hierhin vorgestellten Konzepte der Interprozeßkommunikation ist die Tatsache, daß die Kommunikation nicht über ein Netzwerk erfolgen konnte. Deshalb wurden verschiedene Möglichkeiten geschaffen, eine solche Verbindung zu ermöglichen. Einerseits sind dies die mit System V.3 eingeführten Streams, andererseits die im BSD-UNIX-System enthaltenen Sockets.
Ein Stream ist ein Pseudotreiber im Betriebssystemkern, das heißt das hinter dem Treiber anfangs kein physikalisches Gerät steht, sondern nur Softwarefunktionen. Dieser Treiber stellt eine Schnittstelle zwischen Programm und Betriebssystem zum Austausch von Daten zur Verfügung, wobei der Transfer vollduplex, also gleichzeitig in beide Richtungen, erfolgen kann. Neben speziellen Funktionen erlauben Streams auch Standard-Ein-/Ausgabefunktionen.
Ein solcher Datenweg besteht aus folgenden Komponenten: dem Stream-Kopf, einem oder mehreren optionalen Verarbeitungsmoduln und einem an den Stream angekoppelten Treiber. Dieser Treiber kann nun entweder ein physikalisches Gerät oder erneut ein Pseudotreiber sein. Eine wichtige Eigenschaft der Streams ist die Tatsache, daß die Verarbeitungsmoduln dynamisch eingefügt und auch wieder entfernt werden können.
Ein Socket läßt sich als Datenendpunkt zur Kommunikation zwischen Prozessen betrachten. Sockets sind wie Streams bidirektionale Datenpfade. Der vom Benutzer sichtbare Teil der Kommunikation besteht aus drei Teilen: dem Socket-Kopf (socket layer), dem Protokollteil (protocol layer) und dem Gerätetreiber (device layer). Sockets gibt es in zwei unterschiedlichen Typen, dem Stream-Typ, der eine virtuelle, geschützte und verbindungsorientierte Informationsübermittlung zur Verfügung stellt, und dem Datagram-Typ, der das Versenden von Nachrichten an mehrere Adressaten ermöglicht.
Zum Aufbau einer Kommunikationsverbindung baut der Serverprozeß zunächst mittels ,,socket`` einen Kommunikationspunkt auf. Ein Kunden-Prozeß koppelt sich ebenfalls mit ,,socket`` an einem Kommunikationspunkt an und beantragt dann mit ,,connect`` einen Verbindungsaufbau. Der Serverprozeß muß nun mit ,,listen`` dem System bekannt machen, daß er Verbindungen akzeptieren will, auf die er mit ,,accept`` wartet, bis ein Kunden-Prozeß eine Verbindung anfordert. Ist dies geschehen, erhält er wiederum mit ,,accept`` einen neuen Socket-Deskriptor, über den dann der Austausch von Daten erfolgen kann. Mit ,,shutdown`` wird die Verbindung abgebaut.
Der große Vorteil der Sockets liegt darin, daß durch das Erzeugen eines Sockets gleichzeitig für Sender und Empfänger jeweils eine dem Socket entsprechende Datei erstellt wird. Der Ablauf der Kommunikation über Sockets ist daher analog zum Beschreiben und Auslesen von Dateien, wobei der Sender Daten in seine Datei schreibt, die der Empfänger dann aus seiner Datei auslesen kann.
Eine weitere Methode der Interprozeßkommunikation über ein Rechnernetz ist der Einsatz von Remote Procedure Calls (RPC). Ein Remote Procedure Call ist ein ,,Aufruf einer Prozedur, die an einem anderen Rechner (remote) ausgeführt wird`` [SCHO94, Seite 85,]. Der Ablauf eines RPC zwischen einem Client, der Rechner, auf dem die Prozedur aufgerufen wird, und einem Server, der Rechner, auf dem die Prozedur ausgeführt werden soll, ist folgender:
Zunächst ruft der Client die lokale Prozedur Client-Stub auf, die dann die Ausführung fortsetzt, indem sie die Argumente für die aufzurufende Prozedur in eine Nachricht verpackt, um sie dann zum Server zu übertragen. Dort angekommen dekodiert der Server-Stub, also im Prinzip die Äquivalenz zum Client-Stub, nur eben auf einem anderen Rechner, die erwartete Nachricht und führt dann mit den extrahierten Parametern einen lokalen Prozeduraufruf durch. Von dessen Beendigung informiert, kodiert der Server-Stub die Ergebnisse in eine Nachricht und schickt sie zum Client-Stub zurück, der sie dann wieder dekodiert und an das Anwendungsprogramm übergibt.