Comunicazione client-server locale tramite file o TCP?

Quello che stai cercando di fare è definire un metodo per IPC, o comunicazione tra processi . Ci sono molti, molti modi per farlo.

In generale, i metodi migliori per IPC offrono i seguenti vantaggi:

• Standardizzato, così altri sviluppatori possono guardare il tuo codice e comprenderlo.
• Robusto, compresi i meccanismi di rilevamento degli errori.
• Supportato dalla tua piattaforma (sistema operativo, linguaggio di programmazione, ecc.)
• Semplice, che richiede poco o nessun codice a livello di framework sulla tua parte.

Per questi motivi, in genere seleziono TCP / IP.

• È strongmente standardizzato e tutti dovrebbero sapere come funziona.
• Ha meccanismi integrati di rilevamento degli errori e ACK.
• Supportato da praticamente tutte le piattaforme moderne.
• La maggior parte delle implementazioni di libreria sono semplici: fornire informazioni sugli endpoint, ottenere uno stream.
• Il tuo client e server sono attualmente sulla stessa macchina. Se i requisiti futuri cambiano, tutto ciò che devi fare è modificare le informazioni di connessione e funzionerà ancora bene.

Per quanto riguarda il carico utile della comunicazione TCP / IP, questo può essere qualsiasi cosa tu voglia: XML, JSON, oggetti serializzati, qualunque cosa sia conveniente. Tipicamente quando si mescolano i linguaggi, tuttavia, vorrei usare qualcosa come XML o JSON che sono indipendenti dalla piattaforma e leggibili dall'uomo (aiutano con il debugging).

Raccomando vivamente di scrivere casi di test in cui è possibile collegare il flusso in una simulazione che produce o consuma dati. In questo modo puoi testare la tua interfaccia su entrambe le estremità senza che sia necessario un sistema client / server completo e funzionante.

Non comunicare usando i file a meno che non ci sia letteralmente altro modo. Voglio mantenere questa risposta breve e al punto, quindi dirò questo. Ho lavorato con interfacce basate su file. Lo odiavo ogni volta e chiedevo sempre se ci fosse un modo diverso di farlo. Questo è soggetto a errori e klunky.

Predefinito per IO standard .

Usa le prese se hai bisogno di evitare il sovraccarico di creare nuovi processi o di ricreare lo stato per fare il lavoro. E usa i socket TCP se la portabilità e l'estensibilità sono potenziali preoccupazioni. (Potrei sostenere che i socket TCP dovrebbero essere impostati per default se hai bisogno di socket, ma non lo farò!)

Ma ancora più importante, non dimenticare che lo "standard" in IO standard non è un gioco di parole! I flussi standard sono automaticamente presenti, facili da usare e quasi universalmente disponibili.

^{È anche degno di nota, dal momento che sembra che potrebbe essere il tuo caso d'uso, che la maggior parte delle lingue fornisce librerie che rendono spawn i processi figli e comunicano con loro tramite STDIO quasi allo stesso modo.}

Suggerisco di creare una coppia di socket SOCK_STREAM. Il vantaggio delle coppie di socket è che, a differenza dei tubi, sono bidirezionali. Su alcuni sistemi operativi, le pipe sono anche bidirezionali, ma non dovresti fare affidamento su questo.

Un altro vantaggio delle coppie di socket è che non è necessario un identificatore univoco come un numero di porta o un nome di file per loro.

Come implementarlo realmente: il processo C ++ deve conoscere il descrittore di file della sua estremità della coppia di socket, in modo da poter passare tale intero come argomento della riga di comando.

Se i tuoi requisiti cambiano e il processo C ++ viene avviato separatamente e non dal programma Python, puoi sempre avere un nome per il socket usando i socket di dominio Unix.

Inoltre, se i tuoi requisiti cambiano ancora di più e il programma C ++ viene eseguito su una macchina separata, dovrebbe essere relativamente indolore cambiare usando TCP.

Nota che i socket SOCK_STREAM potrebbero non necessariamente conservare le dimensioni dei messaggi. Quindi, se i tuoi messaggi non sono singoli byte ma piuttosto blocchi di byte, devi anteporre la lunghezza del blocco in ordine di byte di rete al messaggio. Ciò garantisce che il lettore sappia quanti byte devono essere letti.