Aber : Nein, erstmal muss der Transfer auf dem eigenen PC realisiert werden, also "COM". Danach der Transfer über PC's im Netzwerk, also "DCOM".
Bei Transfer der Pakete über "COM" bleibt erstmal alles dem OS (hier nun mal nur M$) überlassen. Damit ist der Sack zu.
Danach können wir uns über die "richtigen" Pakete über's Netz unterhalten.
Die "richtigen" Pakete kann der PC auch an sich selbst schicken. Dafür kennt Linux das "loop back interface" lo, damit kannman so ziemlich jede Client-Server-Kommunikation auf einem Rechner Abbilden.
Aber mir geht es gar nicht um COM und DCOM.
Die können eine Menge. Ein Objekt kann ein ganzes EXCEl-sheet sein, samt eingebetteten (OLE-)Objekten. OPC nutzt nur einen kleinen Teil davon.
Das folgende kann im Detail ziemlich weit neben der Realität liegen, aber im Prinzip sagt der OPC-Client:
"Server, liste mir die Objekte auf."
Der Server sagt:
"Nr:1 typ:integer Bezeichnung:Merkerwort_1 Wert: 17"
...
"Nr:22 typ:integer Bezeichnung:Merkerwort_22 Wert: 177"
oder:
"Nr:1 typ:array of integer Bezeichnung:Merkerworte Wert(1,2,3,17,...177)"
Das alles natürlich binär verschlüsselt. (D)COM übermittelt
Aktualparameter für einen Funktionsaufruf im anderen Programm oder auf dem anderen Rechner. Das Umkodieren in eine gemeinsame Schreibweise und das Anhängen von Metainformationen (wieviele Bytes, die 4 Bytes sind float oder longint) heißt im COM-Jargon "Marshalling". Statt das bei jedem übertragenen Wert nach den Regeln zu generieren, würde der Pseudo-OPC-Server in eine Muster-Bytefolge für ein "marshalled float" den richtigen Wert reinkopieren und das Ergebnis an das Paket anhängen.
Von Objekte, Methoden, Marshalling und remote procedure calls muß er dazu nix wissen.