La domanda è un po 'diffusa, quindi ti suggerisco principalmente di pensare a quale può essere raffinato per essere più specifico.
Questo si applica essenzialmente alla progettazione del protocollo del livello di applicazione (a volte incluso il livello di sessione). Il protocollo del livello di applicazione ha gli elementi seguenti
A. definizioni di messaggi:
Di quanti messaggi hai bisogno? HTTP ha GET, PUT, POST come usato principalmente. Quali sono le indispensabili comunicazioni uniche tra client e server? Quale messaggio ha seguito quale altro ha senso - e quali no?
B. progettazione della struttura e codifica dei messaggi:
Quando i socket ricevono una lunghezza arbitraria di byte - le attività primarie sono trovare dove inizia il nuovo messaggio e quando finisce? Come vengono rappresentati i byte: ASCII, binario, B64, ASN.1?
C. È statico o stateless?
Se esiste uno stato che deve essere gestito dal server durante l'esecuzione del messaggio / comando o tra più richieste, allora quella macchina a stati deve essere coerente e robusta; tutti gli ordini di eventi devono essere indirizzabili da questa macchina a stati per garantire che il protocollo non entri nel deadlock.
D. Esiste una sessione, l'autenticazione o qualche identificatore?
L'identificazione di chi sta parlando con chi, se uno è autorizzato e / o l'autenticazione è valido (durante la sessione) e il mantenimento di tali sessioni diventa la chiave per garantire che le persone giuste ottengano le giuste informazioni.
Qualsiasi progetto di protocollo del livello applicazione ha davvero le domande a cui rispondere. Queste sono cose che ho imparato quando ho esplorato BEEP . Vi lascio a voi se vi è utile o no. Tuttavia, vi è una grande quantità di apprendimento da esso; e hai ragione nel contesto di esso.
Vedere:
1. Una panoramica di BEEP - The Internet Protocol Journal - Volume 5, Number 2
2. BEEP, capendo perché è stato creato, Marshall T. Rose
3. Creazione di applicazioni orientate alle porte e BEEP