Newsgroup: it.comp.lang.visual-basic
Titolo: [semi OT] Protocolli di comunicazione

Ciao a tutti.
Per motivi che non sto a spiegare mi ritrovo a dover gestire la 
comunicazione tra due oggetti Winsock (TCP/IP).
Il punto è: dato che da qui devono passare comandi e risposte con la 
seguente struttura logica:
COMANDO PARAMETRO1 PARAMETRO2...PARAMETRON
La mia idea era di gestire la cosa con il classico sistema a TAG
[inizio]COMANDO[separatore]PARAMETRO1[separatore]PARAMETRO2...PARAMETRON[fine]
Dato che i parametri potrebbero essere di natura binaria, e quindi 
contenere i miei tag, sballandomi la comunicazione, qualcuno mi sa 
indicare un sistema furbo per gestire la cosa?
Ciao

 ha scritto nel messaggio
news:bn314i$sg3p1$1...@ID-184808.news.uni-berlin.de...

2 strade:
1) usare un tag mooolto strano, pieno di caratteri "specili" riducendo al
minimo le possibilità di "conflitto"
2) come fa la "mail", dove "acapo, punto acapo" chiude la mail, o in sql
dove per mettere l'apice: lo raddoppi.
nel binario (ma NON nei tuoi tag), se trovi la stringa da non usare, la
raddoppi.
quando decodifichi, rimuovi i doppi (replace (stringa,TAGTAG,TAG)
So di essere stato chiarisssssssssimo ;-) se però non abbastanza, dimmelo e
ci riprovo.

 indicare un sistema furbo per gestire la cosa?
umm umm non ho capito la tua ultima richiesta, in che senso ti sballano la
comunicazione ?
il messaggio lo hai, aggiungi dei tag noti e spedisci, all'arrivo dei
togliere i tag noti e avrai il tuo messaggio originale, cerca di spiegare
meglio che probl hai , magari codificato in binario temi che i tuoi tag ti
shiftino i valori del messaggio ? Se proprio e' cosi e ne hai bisogno dai
una lunghezza fissa ai tag, tipo 1 nibble e cerca 3 4 valori noti che non
dovrebbero occorrere nel tuo messaggio !
-- 
-Gigio@Work(?)-

 indicare un sistema furbo per gestire la cosa?
Ad esempio aprendo due canali di comunicazione: uno per i comandi e l'altro
epr i dati binari... un po' come fa l'ftp (vedi relativa rfc)
hth

 comunicazione ?
...nel senso che il suo dato "binario" potrebbe contenere proprio il tag, ed
il suo parser interpreta il dato binario come tag...
x ZANNA:
ho una terza idea, forse la più semplice/efficiente:
dopo il tag, inserisci la lunghezza della stringa binaria, così sai
esattamente quanti bytes leggere e lì dentro NON fai parsing.
es [immagine]15718,(ora seguono 15718 bytes di "binario", che, sapendo
esattamente dove iniziano (dopo il >) e finiscono (15718 bytes più in là) ,
non ti danno più problemi)

 indicare un sistema furbo per gestire la cosa?
Se devi includere tutti i pesi (0-255) (se no ti basta usare quello escluso
come delimitatore) e se i dati possono contenere esattamente le tue Tags,
IMHO, non v'è certezza e quindi (per la legge di Murphy) capiterà appena
dopo avviato il tutto, mai in fase di test. Seriamente, se le tags possono
essere contenute nei dati (salvo "detaggarle" aggiungendo qualche salto
mortale), l'idea delle Tags non può andare.
Non mi dispiace affatto l'idea di Lord, se applicabile nel tuo caso.

 Ciao
Cosi di primo getto io ti consiglierei di utilizzare un struttura xml in
modo da poter inserire i dati binari codificandoli in base 64 senza troppe
beghe per il parsing.
Magari ogni client potrebbe avere un file xml con la lista dei comandi
accettati e dell' MD5 del comando in modo da evitare corruzione dati ecc.
Ciao


Giusto per dare un altra alternativa (quella di Lord mi pare ottima)
Potresti aggiungere il numero di byte di ogni tag e parametro:
[inizio]COMANDO[N.byte separatore][n.byte
parametro][separatore]PARAMETRO1[N.byte separatore][n.byte
parametro][separatore]PARAMETRO2...PARAMETRON[fine]
ciaociao

 Potresti aggiungere il numero di byte di ogni tag e parametro:
Ma se nei dati una tag viene parimenti citata rischieresti di riprodurre
anche questo, no?!

 riprodurre anche questo, no?!
no, perchè sui dati binari, che sai dove cominciano e dove finiscono, non
vai a fare verifiche.
--
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo


no, perchè chiaramente i parametri che specificano il numero di byte sono a
lunghezza fissa:
'ok, questo lo riconosciamo sicuramente
[inizio]
'questo potrebbe essere a lunghezza fissa oppure si potrebbe specificare la
lunghezza anche qui
COMANDO
'con questo sappiamo che dopo 4 byte (per esempio) i prossimi N byte sono il
parametro
[N.byte separatore][n.byte parametro]
'qui sappiamo esattamente quanti byte dobbiamo leggere prima di incontrare
il prossimo parametro
[separatore]PARAMETRO1
mi è sfuggito qualcosa?
ciaociao

 mi è sfuggito qualcosa?
Stando alle dichiaraziuoni di Zanna, sì (e risponderei anche a CSSoft).
Se la mia Tag rischia di essere parimenti (=identicamente) citata, verrebbe
parimenti citata l'intera Tag, comunque la possa complicare, anche nei dati.
In altre parole: Se, analizzando quel che ho (quindi anche gli stessi dati),
rischio di trovare una Tag su cui faccio affidamento solo per il fatto che
sta nei dati.
In altre parole ancora:
Immaginiamo di scrivere un help per le modalità sintattiche di un certo
strumento.
Bene, in questo help, se gestito dallo strumento stesso, non potremo MAI
scrivere quelle tag nella loro sintassi esatta... O no?

 anche nei dati.
ovvia, lupo... (non ovvia nel senso di facile, ma "o via", alla toscana :-)
se io ho una cosa fatta cosě:
tag1 16caratteri
tag1 16caratteri
per il protocollo che mi sono dato la prima riga č una tag, la seconda,
nonostante abbia lo stesso contenuto, č un dato.
La limitazione di questo tipo di protocollo č semmai che deve sempre essere
letto "sequenzialmente", dall'inizio, per non incorrere in errori, e non
potresti utilizzare ricerche di tipo "instr".


 MAI scrivere quelle tag nella loro sintassi esatta... O no?
Questa non l'ho capita...
ciaociao

 errori, e non potresti utilizzare ricerche di tipo "instr".
Infatti, o, meglio, non saresti mai certo che il primo risultato
dell'eventuale Instr corrisponda a una Tag "vera". E le altre, eventualmente
presenti sin dall'origine...?

 COMANDO PARAMETRO1 PARAMETRO2...PARAMETRON
Ho avuto lo stesso problema per una comunicazione seriale.
Il metodo che ho utilizzato è stato:
<carattere_inizio_blocco><comando><lunghezza_blocco><blocco><XOR>
Probabilmente perdi un bel pò di caratteri, pero' se si tratta di una
comunicazione continua, hai bisogno di un certo margine di sicurezza.
Praticamente in questo modo hai un carattere iniziale che ti consente di
capire l'inizio del blocco che volendo si puo' anche togliere, ma ti aiuta
a capire dov'e' l'inizio del messaggio.
Ti faccio un esempio: mettiamo che il tuo protocollo supporti i comandi da
"1" a "1000". Ora, se per caso ti arriva un pacchetto troncato e quindi il
primo dato che hai non è il comando ma chissà che cosa, potresti
interpretare un comando per un altro; invece cosi' già puoi fare una prima
pulizia dei pacchetti troncati. Ovviamente non è una soluzione completa,
nel senso comunque che ti potrebbero benissimo arrivare pacchetti troncati
che inizino con <carattere_inizio_blocco>, ma sicuramente la probabilità
diminuisce. Insomma, puoi fare una prima pulizia dei dati che ti arrivano
cercando il carattere <carattere_inizio_blocco> e da lì proseguire
l'interpretazione dei dati.
Tornando al protocollo, poi segue il comando e la lunghezza del blocco; la
lunghezza del blocco ti è utile per capire quanti bytes leggere; alla fine
del <blocco>, fai lo XOR (o un'altra funzione) dei dati ricevuti e lo
confronti con lo <XOR> del pacchetto arrivato; questo è un altro metodo per
vedere se il contenuto del pacchetto è effettivamente quello che è stato
inviato dalla sorgente. 
-- 
Ciao,
        Fabrizio
<=- 
http://www.negusweb.it
 -=>

 Questa non l'ho capita...
Mi sembra invece molto semplice: Se una Tag ti serve per agire
conseguentemente, dai per scontato di trovare _solo_le tue Tags, non i
duplicati delle stesse in quello che stai analizzando.
Insomma, se le Tag vengono ripetute (o rischiano di...) nei dati, non c'è,
IMHO, altro modo che separare fisicamente e logicamente le "sintassi" (e
quindi la considerazione delle tags) dai dati (nei quali le tags possono
essere impunemente citate, ma tanto non verranno considerate dall'analisi
della sintassi)

 Ma se N byte viene citato nei dati?
Scusa Lupo, ma.... CHISSENEFREGA SE VIENE RICITATO! ;-)
č come se il protocollo interpretasse pacchetti a lunghezza fissa!
Prova a vederla cosě:
se io ho un pacchetto con campi a lunghezza fissa so esattamente quali sono
i tag e quali i dati giusto?
ok, se poi su 6 "tipi" di tag (ovvero 'inizio' , 'comando', 'lunghezza
separatore' , 'lunghezza dato' , 'dato' e 'fine') solamente 1 č a lunghezza
variabile e io so esattamente dove inizia e quanto č lungo non posso
sbagliare!
Come dice giustamente CSSoft poi, c'č la limitazione di dover interpretare
il pacchetto sequenzialmente. Se si vuole usare la InStr allora č giusto
quello che dici
ciaociao

 Questa non l'ho capita...
Per spiegarmi meglio, e meglio mi spiegherò se chi mi legge usa QuetoFis per
OE:
Quella che segue è una faccina ;-) la vedi, no?!
Se devo spiegare a qualcuno come inserire una faccina, non potrò mai
scrivere (se lo strumento che mostra il mio testo è lo stesso che sto
descrivendo), ma ora lo faccio apposta, per fare la faccina sorridente devi
digitare ;-) , ma dovrò scrivere "digita ; - ) senza spazi intermedi.
La faccina, ovvero ; - ) (senza spazi intermedi) è una Tag per QuoteFix...
e, quarda caso, sta nei "dati" che lo stesso deve trattare e, guarda caso
ancora, la interpreta e riproduce. Zanna vuole evitare questo.

 Scusa Lupo, ma.... CHISSENEFREGA SE VIENE RICITATO! ;-)
Leggi il post sotto. Forse ho frainteso, ma il problema che Zanna ha posto
(sempre se non ho frainteso) l'ho incontrato piů volte. Quindi: O un
carattere segato dai dati (non sempre possibile, specialmente coi binari) da
usarsi come delimitatore nelle tags o dati separati dalla sintassi (tags)
degli stessi. Insisto: NON C'E' ALTRO VERSO!

 dalla sintassi (tags) degli stessi. Insisto: NON C'E' ALTRO VERSO!
Dai, Lupo...
L'idea che stanno cercando di spiegarti è giusta.
E, del resto, è quello che usa qualunque 'compressore' binario, da winZip a
Arj, Jpg, ecc...
Se io devo comunicarti un parametro che si chiama Pippo, che sarà poi
seguito dal parametro Pluto, ma il parametro Pippo vale proprio 'Pluto',
avrei un casino. E fin qui siamo tutti d'accordo.
Se invece io scrivo:
Il Parametro Pippo è lungo 5 caratteri: Pluto
Il Parametro Pluto è lungo n caratteri: djkddshh
ho risolto il problema.
Infatti il parser inizia, trova che il prossimo parametro è Pippo, e che è
contenuto nei successivi 5 caratteri. Quindi prende 5 char e NON LI
INTERPRETA.
Poi riprende a ragionare dal 6°, e così via...
Ciao
alberto

 typed:
[...]
Hanno ragione loro: se tu nel tag dici _anche_ quanto sarà lungo il dato (e
quindi implicitamente quale sarà la posizione del tag successivo nella
stringa) non avrai problemi a distiguere i tag da dati (partendo dal
presupposto che all'inizio di tutto ci sia sempre un tag).
btw in questo caso va previsto un checksum e un resend eventuale dei dati...
lavorando in tcp/ip alcuni pacchetti potrebbero andar persi... questo va
considerato in ogni caso.

 Zanna vuole evitare questo.
E così facendo lo eviterebbe! ;-)
ciaociao


Certamente. Gli eventuali problemi di trasmissione vanno sempre considerati,
[modalità_sottovoce=True]
...ma prima di dirlo a Zanna volevo aspettare che approvasse il protocollo!
;-)))))
[modalità_sottovoce=False]
ciaociao

 Poi riprende a ragionare dal 6°, e così via...
Sì, mi avete convinto.
Mi scuso con tutti per le insistenze, ma mi sfuggiva il particolare che hai
maiuscolato, chiaramente fondamentale.

 che hai maiuscolato, chiaramente fondamentale.
Ah ecco! Se lo dice Albe allora va bene eh?!?! PLONK
.
.
.
.
.
.
.
.
eheheh......scherzetto! ;-)
ciaociao

> Sě, mi _avete_ convinto. ;-)

 tag, ed il suo parser interpreta il dato binario come tag...
umm vero, la tua propposta dell'header e' la cosa migliore, esistono
codifiche semplici tipo il PDU ( o tpu)che si usa nella comunicazione di
alcuni cellulari con il pc che sono semplicissimamente codificati in binario
cosi :
[TIPO][LUNGHEZZA][Dati....][TIPO][LUNGHEZZA][Dati....][TIPO][LUNGHEZZA][Dati
....]
es:  01 20 749817654023650732465073...
Tipo = 01 =  Immagine
Lunghezza = 20 = 20Kbyte
Dati = immagine binaria
ti consiglio una codifica a 8bit con riempimento con zeri cosi da essere
ancora piu' preciso col parseR ^_^
-- 
-Gigio@Work(?)-

Salve, stiamo organizzando un pestaggio di massa a lupo per il meeting, chi
volesse partecipare e' pregato di portarsi da casa l'armamentario grazie !
:PpPp
-- 
-Gigio@Work(?)-

> PpPp
Slinguaccia fin che vuoi, ma ho usato il plurale nelle prime righe di quel
post, poi l'ho pure auto-quotato. Infine ho seguito il ramo. Per il
pestaggio, io sono un lupo strano che dà poche soddisfazioni, ... abbasso
subito la coda. Ho detto _abbasso_ :-P

 abbasso subito la coda. Ho detto _abbasso_ :-P
Auff... gara di rutti allora ?
-- 
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/

 Auff... gara di rutti allora ?
No, mi alzerei al volo, mi riferivo alla protezione dell'antro...

 No, mi alzerei al volo, mi riferivo alla protezione dell'antro...
auff (2) ma con voi non si fa mai nulla di divertente ? ^_____^
