Comunicazione tra lingue

Per la comunicazione tra due programmi (processi), abbiamo bisogno di Comunicazione tra processi (IPC)

I socket vengono spesso utilizzati anche per processi su una singola macchina. Ad esempio, ci sono molti strumenti su server HTTP e API REST che possono essere utilizzati in questo modo. Il vantaggio dei socket è che hanno un indirizzo globale (numero di porta), quindi qualsiasi processo può stabilire una connessione.

Talvolta viene utilizzata la comunicazione tramite file, soprattutto se alcune directory vengono utilizzate come una casella di posta elettronica che verrà elaborata in un secondo momento. In pratica, questo è abbastanza complicato: il processo di scrittura deve utilizzare nomi di file univoci e il processo di ricezione deve osservare la directory. E non c'è un modo semplice per inviare una risposta.

Per i processi locali, il principale meccanismo di comunicazione è pipe. I pipe sono flussi anonimi e unidirezionali forniti dal sistema operativo. I pipe sono particolarmente importanti su sistemi operativi Unix come Linux, dove molti strumenti sono scritti in un modo che consuma dati da stdin e scrive l'output su stdin. Ciò consente a molti di questi strumenti di essere concatenati insieme in una pipeline più grande . All'applicazione, i tubi appaiono come normali flussi di input / output.

Poiché le pipe sono anonime, un'applicazione non può connettersi a una pipe esistente. Invece, i tubi sono creati da un processo genitore. Quando il genitore genera un processo figlio, le pipe (e altri descrittori di file) vengono ereditate dal genitore. Per la comunicazione bidirezionale tra un genitore e un figlio o tra due processi fratelli, è comune creare una coppia di tubi. Dopo che i processi sono stati generati, ciascun partner di comunicazione chiude un'estremità della pipe, quindi ogni processo ha una pipe per la lettura e una pipe per la scrittura.

Un metodo di comunicazione di livello relativamente basso è la memoria condivisa. Il sistema operativo ha la capacità di rendere visibile una certa quantità di memoria a più processi, così ora tutti possono leggere o scrivere dati liberamente in quella regione di memoria. Tuttavia, tutti i processi devono ora concordare su alcuni formati binari e devono utilizzare un protocollo di sincronizzazione per evitare di sovrascrivere le modifiche reciproche. Nonostante questi problemi, la memoria condivisa può essere una buona soluzione se più processi devono modificare gli stessi dati in modo molto efficiente. Altrimenti, sarebbe più comune creare un server che gestisca i dati e accetta richieste (ad esempio tramite un socket) per l'accesso ai dati e amp; modifiche.

Prendendo i due programmi Java come punto di partenza, entrambi questi programmi hanno implicitamente acconsentito al formato dei messaggi EG 8 bit per un byte, quindi molti byte per una parola, così tante parole per un pacchetto, e cosa il significato di una parola specifica in un pacchetto è.

Tuttavia, una volta ottenuto tale accordo, non importa in quale lingua vengono scritti gli endpoint finché entrambi compilano e interpretano i dati nello stesso modo. Quindi programmi scritti in lingue diverse possono scambiarsi pacchetti e tutti sono felici.

Ora il contenuto di questi packer può anche avere un livello più alto, il che significa che entrambi i finali sono d'accordo. Il contenuto potrebbe essere dati binari non elaborati, stringhe di testo semplici o persino essere formattati come strutture di livello superiore Ad esempio messaggi HTTP o dati XML o JSON. Ma l'accordo sul significato da entrambe le estremità è la cosa fondamentale.

L'unica parte difficile è quando hai due macchine diverse che comunicano con diverse Endianess . Ciò importa solo quando i dati arrivano al mezzo fisico di trasmissione. A questo punto ci sono soluzioni standard per farlo attraverso l'accordo di network byte order (vedi il link precedente)

È specifico per l'implementazione (in particolare ABI & chiamata convenzione specifica).

Molte implementazioni linguistiche forniscono un modo per chiamare una funzione (nello stesso programma e processo ) in alcuni altra lingua (spesso C). Potrebbe essere chiamato Interfaccia di funzione straniera .

Per Java, leggi su JNI .

Per Python, leggi Estensione e amp; Incorporamento dell'interprete Python .

Per Ocaml, leggi il capitolo su Interfacciamento C con Ocaml .

etc ....

But what if those programs were written in different languages? You could conceivably use files, but are there any other ways of communicating?

Sì, si chiama comunicazione tra processi . Linux fornisce molti modi per farlo attraverso le sue chiamate di sistema (elencate in syscalls(2) ...), pipe (7) -s, socket (7) -s, signal (7) -s, shm_overview(7) , sem_overview (7) etc etc ...

Leggi anche Sistemi operativi: tre pezzi facili

"Scritto in"!="Può comunicare con"

I know how, for example, to communicate between two java programs if I needed to. If I had two programs on two different machines, I could use sockets and streams. But what if those programs were written in different languages? You could conceivably use files, but are there any other ways of communicating?

Utilizzerai le stesse tecniche se i due programmi sono scritti nella stessa lingua o in lingue diverse.

Il linguaggio che un sistema può comunicare con non ha niente a che fare con il linguaggio che è scritto . Il tuo browser Chrome, ad esempio, è scritto in c ++, ma la lingua che "parla" è HTTP. Il server Web, purché conforme alle specifiche HTTP, può essere scritto in qualsiasi lingua e funzionerà comunque. E ci sono molte lingue con librerie che consentono loro di comunicare via HTTP.

Lo stesso vale per altri protocolli di comunicazione, inclusi EDI, ODBC, SMTP, tu lo chiami. Se dovessi prendere Wireshare e guardare ciò che viene inviato attraverso la rete, non vedrai alcun codice Java o C ++. La lingua in cui è scritto il programma è totalmente irrilevante.

In effetti, se disponevi di un protocollo che superava c ++ o Java sul filo, ci sarebbero due enormi problemi:

(1) Sarebbe incredibilmente difficile da gestire, perché la maggior parte dei programmi, in fase di esecuzione, non capiscono nemmeno la lingua in cui sono scritti; il compilatore può leggere quella lingua, ma emette sia il linguaggio macchina o una sorta di linguaggio intermedio (bytecode per Java o IL per C #, ad esempio). È spesso il caso che il tempo di esecuzione non capisca affatto il codice sorgente.

(2) Ci sarebbe una grande esposizione alla sicurezza, dal momento che tutto ciò che viene inviato su tale protocollo sarebbe ampiamente aperto a un'iniezione attacco .

Hai già identificato una possibile soluzione: flussi di dati su socket. Funzionerebbero altrettanto bene per due processi scritti in lingue diverse come se fossero scritti entrambi in Java.

I socket sono stati tradizionalmente forniti dalle specifiche del sistema operativo sottostante e / o dalle librerie standard del sistema operativo, e tradizionalmente la maggior parte dei linguaggi di programmazione fornisce una libreria che può interfacciarsi con l'implementazione del socket fornita dal sistema operativo.

Quindi supponiamo che sia così: che puoi connettere un processo C in esecuzione e un processo Java in esecuzione insieme usando socket locali o di rete.

La tua vera domanda è, cosa viene passato sul socket?

La risposta è: qualunque cosa tu voglia. Il sistema operativo passerà volentieri i bit avanti e indietro, devi decidere cosa significano quei bit per i tuoi processi.

Gli esempi potrebbero includere BSON, XML, buffer di protocollo, Unicode, documenti di parole compresse, immagini PNG e quant'altro. Dipende da te come programmatore per codificare i tuoi programmi Java e C che stanno leggendo e scrivendo i dati sul socket per sapere cosa fare con i dati e cosa significa.

L'approccio generalmente accettato e più basilare a questo sarebbe la creazione di un'API REST. Utilizzare JSON come formato dei dati potrebbe semplificarti le cose.