Progettazione di un protocollo applicativo [chiuso]

Question

Ho un'applicazione standalone esistente che verrà estesa da una terza parte, utilizzando un protocollo di rete. Le funzionalità sono già implementate, tutto ciò di cui ho bisogno è esporle all'esterno.

Supponendo che sia già stato scelto il protocollo di trasporto (UDP), ci sono risorse che mi aiuteranno a progettare il mio protocollo applicativo?

Sembra che ci siano molte informazioni sulla progettazione del software, ma non sulla progettazione del protocollo. Ho già esaminato Progettazione di protocolli applicativi .

Answer 1

Vedi Linee guida per la progettazione dei protocolli Jabber e RFC 4101 . Sebbene abbia lo scopo di rendere le RFC più facili da comprendere per i revisori, questa RFC fornisce alcuni consigli interessanti.

Answer 2

Hai guardato Buffer protocollo Google ? Sembra un buon modo per risolvere questo problema.

È possibile creare un endpoint che comunica con l'app esistente e quindi risponde "dall'esterno" utilizzando il protocollo protobuffer. È binario, quindi è piccolo e veloce e non devi scrivere il tuo gestore di protocollo, perché puoi usare quelli di Google. Il rovescio della medaglia è che deve essere implementato su entrambi i lati del sistema (sul lato 'server' e sul lato consumatore / client).

Answer 3

Un altro consiglio per buffer di protocollo - binario stretto e carino con poco sforzo. Si noti, tuttavia, che mentre il protocollo binario è ben definito, non esiste ancora uno standard RPC concordato ( molti sono in corso , tendendo a inclinarsi verso TCP o HTTP).

Le specifiche rendono molto semplice avere client e server in diverse architetture , il che è positivo, inoltre è estensibile.

Avvertenza: sono l'autore di una delle versioni .NET , quindi potrei essere di parte ;-p

Answer 4

Prima di tutto, UDP è principalmente un metodo di trasporto broadcast unidirezionale. Inoltre, è potenzialmente in perdita , quindi devi essere in grado di gestire i pacchetti mancanti e i pacchetti fuori servizio. Se hai bisogno di un livello di affidabilità di UDP o di connessioni a due vie, finirai per aver bisogno praticamente di tutto da TCP, quindi potresti anche iniziare con quello e lasciare che lo stack di rete si occupi di esso.

Successivamente, se i tuoi dati sono potenzialmente più grandi di un singolo pacchetto IP, avrai bisogno di un modo per identificare l'inizio e la fine di ogni pacchetto e un mezzo per gestire i pacchetti illegali o corrotti. Consiglierei un tipo di intestazione con lunghezza del pacchetto, un tipo di piè di pagina e forse un checksum.

Quindi hai bisogno di un modo per codificare i messaggi e le risposte. Ci sono molti protocolli RPC in giro. Puoi guardare SOAP o progettare un protocollo personalizzato basato su XML o binario.

Answer 5

Dovresti davvero pensare seriamente se vuoi davvero progettare, documentare e mantenere il tuo protocollo o usare qualcosa che è già esistente. È probabile che esista già un protocollo documentato che soddisfa le tue esigenze. A seconda di ciò che stai facendo, probabilmente sembrerà eccessivo all'inizio e l'implementazione di tutte le specifiche sembrerà noiosa e molto meno divertente rispetto alla scrittura della tua, ma se intendi che la tua applicazione sia ancora attivamente sviluppata in pochi anni, dovrebbe salvarti un sacco di tempo e denaro per usare qualcosa che esiste già ed è noto a terzi. Inoltre, se puoi utilizzare una libreria esistente per quel protocollo, la parte di implementazione dovrebbe essere molto più veloce.

Progettare un nuovo protocollo è più divertente che implementarne uno ma meno che mantenerne uno poiché devi convivere con tutti i difetti. Nessun protocollo è perfetto ma se non ne hai mai progettato uno, puoi essere certo che commetterai più errori nel progettarlo rispetto alle persone che hanno progettato il noto protocollo esistente che potresti usare invece.

In breve, sfrutta ciò che già esiste quando possibile.

Answer 6

Se non vuoi costruire il tuo protocollo da zero, dovresti dare un'occhiata a SOAP . Il supporto varia a seconda dei diversi linguaggi di programmazione, ma la comunicazione tra lingue è esplicitamente incoraggiata.

Sfortunatamente UDP e SOAP sembrano essersi bloccati nella sua infanzia, HTTP è il più comunemente usato.

Answer 7

Se scegli XML, tieni presente che avrai un enorme overhead di markup.

Un semplice protocollo binario non avrà bisogno di troppe risorse per analizzare rispetto a XML.

Answer 8

  

Ho un'applicazione autonoma esistente che verrà estesa da una terza parte, utilizzando un protocollo di rete.

Sarebbe utile sapere qualcosa in più su ciò che fa il tuo programma e quale sia la natura di queste estensioni di terze parti. Forse qualche razionale per l'utilizzo di UDP?