Progettazione di messaggistica CLI server-client

Question

Progettazione di messaggistica CLI server-client

#1 da (2 voti)

2

Sto realizzando prototipi di macchine singole, software per singolo utente con un modello client-server; il primo client per il quale sarà una CLI, ma mi aspetto che una webapp / GUI (locale) venga in seguito.

Per la CLI, mi piacerebbe essere in grado di connettermi a un'istanza del server esistente per eseguire qualsiasi comando, o avviarne uno per la durata del comando, se non esiste. La GUI avrebbe avviato un server con un tempo più lungo, cioè fino alla chiusura.

Quali sono le buone opzioni per la messaggistica (trasporto) tra client (s) e server qui?

socket Unix? HTTP? AMQP? ZeroMQ? Qualcos'altro?

Mi piacerebbe usare protobuf / cap'n proto, quindi è il trasporto che sto chiedendo davvero - a meno che non ci sia qualche soluzione tutto in uno da raccomandare forse. Mi piacerebbe anche non escludere il supporto di Windows da questa decisione.

design architecture client-server cli

posta OJFord 09.09.2018 - 13:15

fonte

1 risposta

Leggi altre domande sui tag design architecture client-server cli

Come modellare i dati JSON in modo che possano essere facilmente serializzati in semplici classi Java? QA - Comunicazione dello sviluppatore [duplicato]

score 2 · Answer 1

Confronta un tipo di protocollo di comunicazione molto diverso:

POSIX Sockets sono disponibili su tutte le piattaforme abilitate TCP / IP (ad es. linux , windows ) e non solo unix. È un protocollo di comunicazione flessibile. Offre tra le altre possibilità, flussi o pacchetti bidirezionali affidabili bidirezionali. Si adatta alle tue esigenze.
Ma è di basso livello (livello 5 del modello OSI), quindi dovrai garantire la sicurezza (livello 6) e per occuparsi dell'assemblaggio / smontaggio dei messaggi di lunghezza variabile (livello 7).
HTTP (S) è richiesta / risposta, quindi molto adatto per il tuo scopo client / server (livello 7 di OSI, quindi la sicurezza e il confezionamento dei dati sono già disponibili). C'è un piccolo sovraccarico per i dati di intestazione, ma il corpo può essere protobuf binario se vuoi. La sicurezza è gestita dai livelli inferiori. Tuttavia, http non è connesso, quindi dovrai organizzare la gestione della sessione.
Code messaggi (alias protocollo AMQP , libreria ZeroMQ ) non sono pensati per essere bidirezionali per loro natura. Quindi è bene inviare comandi e dati al server, ma come inviare una risposta con i dati al client? Via un'altra coda? Quindi non penso che sia l'approccio migliore per il tuo caso d'uso.

Se il tuo protocollo è per un sistema in esecuzione su una rete locale, ad esempio per scopi di apprendimento, le prese sarebbero un ottimo inizio. Se l'ambito è più grande, http (s) potrebbe essere più appropriato.