Newsgroup: it.comp.java
Titolo: INFO COMUNICAZIONE CLIENT/SERVER CON UDP

Sto creando un'applicazione, di tipo client, che comunica con il
server inviando i pacchetti attraverso DatagramSocket (quindi utilizzo il
protoccolo UDP).
Come posso essere certo che il pacchetto che il client ha inviato è stato
ricevuto dal server? devo implementare manualmente qualcosa tipo
l'handshake a tre vie o esiste una classe che mi permette di effettuare
questi controlli?
Se avete esempi da farmi vedere, link o risorse che pensate potrebbero
servirmi per gestire al meglio l'invio e la ricezioni di pacchetti UDP con
java fatevi avanti
ma non esistone dei metodi forniti da sun del tipo "sendpacchetto" e
"receivepacchetto" che si occupino di fare queste controlli? 
voi avete dei metodi che svolgono questo lavoro?
Ringrazio anticipatamente tutti

 "receivepacchetto" che si occupino di fare queste controlli? 
Uhm... rivedere le basi di UDP.
Saluti
CarMas



ma cosa significa rivedere UDP?
Io invio dei pacchetti con udp, non viene stabilita nessuna connessione.
come faccio ad avere la conferma che il pacchetto sia arrivato a
destinazione? Un pacchetto UDP non ha nessun campo che mi permetta di
fare questo controllo e anche se l'avessi non mi servirebbe
granchè. Però c'è da dire che il protocollo udp contiene due campi con 
l'indirizzo del mittente e del destinatario. 
Una prima stupida soluzione
è la seguente: il client invia un pacchetto e fa partire un timer (dopo
un tot di secondi lancierà un evento), il server quando riceve il
pacchetto risponde al client dicendo di aver ricevuto il pacchetto. Quando
il timer lancia l'evento se il server ha risposto bene, altrimenti lancia
nuovamente lo stesso pacchetto.  Ovviamente questa è una stupida
soluzione, perchè la risposte del server al client potrebbe perdersi e il
client convinto che il server non abbia ricevuto nessuna risposta invia
nuovamente il pacchetto ....con i problemi che ne seguiranno.
Penso sia normale avere dei metodi che mi possano dare la conferma di aver
inviato un pacchetto e che questi siano giunti correttamente a
destinazione.  Posso farli anche io anche se con tutti quelle classi e
metodi offerti da sun mi sembra strano che non ci sia niente al caso
mio....risparmierei tempo e soprattutto non mi dovrei scervellare per una
soluzione che funzioni efficamente.
CarMas, lei mi ha detto di ripassare il protocollo UDP ma cosa in
particolare? cos'è che mi sfugge?
Avete dei programmi open source che posso studiare ? Sapete dove posso
trovarli?
 

Ti sfugge il fatto che il protocollo UDP nn offre nessun tipo di base per 
poter fare questi controlli!
Non capisco perchè implementare un sistema client/server con l' UDP...se nn 
devi trasmettere dati in streaming tipo audio/video usa il TCP...sarà più 
lento..ma tutti questi controlli sono trasparenti e nn te ne devi 
preoccupare!
Ciao 

 particolare? cos'è che mi sfugge?
Le ho detto di ripassare UDP perche' lei dimentica che UDP oltre che 
connectionless e' anche unreliable.
Questo significa che non ha NESSUNA garanzia, a livello di protocollo di 
trasporto, che il pacchetto arrivi a destinazione e che non arrivi 
duplicato, per esempio per problemi all'interno del mezzo trasmissivo. 
In aggiunta, se manda piu' pacchetti, non ha nemmeno nessuna garanzia 
che questi arrivino nello stesso ordine con cui sono stati mandati.
Se l'affidabilita' e' un requisito, allora le suggerisco di passare a TCP.
Nulla le vieta, ovviamente, di implementare nel SUO protocollo un 
algoritmo di attesa e ritrasmissione, ma rischia di entrare in un ciclo 
senza fine. Mi spiego subito: chi le dice che il pacchetto non e' 
effettivamente arrivato? potrebbe essere arrivato ma essersi perso il 
messaggio di risposta del server. Se lei invia di nuovo puo' ricadere in 
una qualunque di queste situazioni (stiamo, ovviamente, ragionando nel 
caso peggiore).
Le ricordo, infine, che la tecnica delle ritrasmissioni e' applicabile 
con sicurezza solo se comporta operazioni idempotenti sul lato server.
Saluti
CarMas



Lo so, sarebbe stato tutto molto più semplice se dovevo utilizzare il
protocollo TCP.
Purtroppo sono costretto ad utilizzare UDP, mi è stato imposto.
Ovviamente chi mi ha detto che devo fare l'applicazione con UDP avrà i
suoi buoni motivi (tra questi potrebbe esserci semplicemente il fatto che
mi costringe ad usare UDP :-).
Cmq non voglio discutere se utilizzare UDP o TCP. 
Voglio risolvere il problema che ho presento. 
Inoltre non penso sia impossibile, già la soluzione che io ho proposto è
un inizio e ragionando in quella maniera e inserendo oppurtuni
miglioramenti  si può giungere a soluzioni accettabili.
Mi sono rivolto a voi perchè cercavo sia una buona soluzione, sia per
sapere se è possibili riclare del codice da qualche parte o prendere
degli spunti interessanti



Inanzitutto grazie della risposta.
Purtroppo sono costretto ad utilizzare il protocollo UDP.
Sono ben conscio dei problemi che lei mi ha presentato: non si può essere
sicuri al 100% che un pacchetto sia giunto correttamente a destinazione
utilizzando UDP. Cmq il client dovrà inviare un solo pacchetto e solo
raramente...non devo scambiare una gran quantità di dati. 
Visto che sono costretto ad utilizzare UDP  volevo sapere o trarre spunto
da codice open source su come avviene una comunicazione client/server dove
lo scambio di messaggi è molto contenuto è ogni messaggio ha piccole
dimensioni. Ci saranno applicazioni che utilizzano UDP ed ero curioso di
come gestivano la connessione. Ovviamente realizzarò il server in modo
che riesca a dialogare con il client come dice lei con
operazioni idmpotenti.
Le faccio presente che sono costretto ad utilizzare UDP. 

 Purtroppo sono costretto ad utilizzare UDP, mi è stato imposto.
cerca reliable udp.
http://www.google.it/search?hl=it&q=java+reliable+udp&btnG=Cerca+con+Google&meta=
ciao
uL
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

caro pippo,.
UDP è un protocollo che NON garantisce la NON perdita ne la consegna
in ordine dei pacchetti....se usi UDP,. la logica della ritrasmissione
devi implementarla a livello applicativo, NON HAI SCELTA.
tipicamente il client fa lal richiesta, aspetta un timeout
(il timeout lo otteni facendo la send in un thread, e quindi una join
su quel thread), dopo di che se la risposta non è arrivata rispedisce.
Questo è il modo con cui ho sempre affrontato il problema!
Stefano

 dimensioni. 
Capisco. A titolo puramente formativo, le posso suggerire questo link:
http://www-lia.deis.unibo.it/Courses/RetiDiCalcolatori/Es_SockJ_Datagram.pdf
dove trovera' un banalissimo esempio di applicazione client/server in 
java basata su datagram.
Quanto al resto, appare evidente che trovare una soluzione 
soddisfacente, sotto tutti i punti di vista, al suo problema e' una cosa 
che viene delegata interamente alle sue doti di progettista. A lei 
quindi valutare i pro ed i contro di ogni possibilita' ed imboccare una 
strada piuttosto che un'altra.
Buon lavoro,
Saluti
CarMas

 questi controlli?
Il three-way-handshaking di TCP serve solo per stabilire la connessione.
UDP e connectionless. Non ha senso. E' come voler affiancare due
biciclette per simulare un'automobile.
Quindi: Se proprio vuoi un controllo sulla ricezione del pacchetto, ti
tocca creare tutto a manina, implementando un sistema stile go-back-n al
disopra di UDP.
-- 
Giambo - Occhio al filtro antispam _e_ alla whitelist !

Grazie a tutti delle numerose risposte.
Mi avete aiutato con i vostri consigli e link segnalati.
Non pretendenvo un'affidabilità al 100%, ma semplicemente come utilizzare
nel migliore dei modo l'invio attraverso questo protocollo. Come
immagginavo sta tutto a me scegliere la situazione migliore, che penso non
sia sempre la stessa...dipende dalla situazione in cui mi trovo.
Non so esistano metodi migliori di qualcunaltro magari basate su regole
euristiche. Il mio caso è abbastanza banale, basta provare a inviare lo
stesso pacchetto n volte.

 questi controlli?
L'unica soluzione che vedo è scriverti un protocollo di comunicazione sopra
l'UDP, che controlli l'invio e la ricezione dei messaggi. 
Mi spiego.
Un protocollo potrebbe essere il seguente:
A vuole inviare un messaggio a B.
Supponiamo che il nostro protocollo sia cosi' fatto:
codice|<id>|<lunghezza_messaggio>|messaggio|
Il codice è necessario per specificare di che tipo di operazione si tratta 
Mettiamo che
codice = 1 => Invio nuovo messaggio
codice = 2 => Ok, messaggio ricevuto
L'id è per capire a quale specifico messaggio stiamo facendo riferimento
(potrebbero esserci più messaggi inviati contemporaneamente. Come faresti a
distinguerli?)
La lunghezza del messaggio ti serve per conoscere quanti caratteri devi
leggere.
Eventualmente, alla fine del messaggio potresti mettere un checksum (un
semplice XOR, per esempio), per controllare la bontà dei dati trasmessi.
Ad esempio, una transazione potrebbe essere la seguente:
A invia un messaggio a B cosi' composto.
1|1|4|ciao
A aspetta di ricevere il messaggio di conferma da B cosi' composto
2|1|0|
Se non lo riceve entro tot secondi (considerato come timeout), può rinviare
il messaggio a B.
Praticamente, cosi' facendo, stai construendo un ulteriore protocollo sopra
l'UDP ... ovvero stai riscrivendo, in modo molto rozzo e poco ottimizzato,
il TCP.
-- 
Ciao,
 Fabrizio
=== 
http://www.negusweb.it
 ===

L'idea e' che 1) su reti IP moderne, le percentuali di perdita di
pacchetti sono bassine (specie se l'applicazione e' usata
prevalentemente in una intranet, dove le varie reti sono sotto il
controllo della stessa organizzazione); 2) per certe applicazioni, TCP
e' troppo ingombrante, quindi un UDP "aumentato" puo' essere parecchio
piu' efficiente (un esempio e' TIBCO Rendezvous).
Cosa serve dipende da situazione a situazione. Per esempio, se si e'
verificato il fatto che UDP e', per dire, effettivamente 95% reliable
su una data rete e che per una certa applicazione una request sta in un
datagram, semplicemente aggiungendo a livello applicativo un request id
univoco ad ogni richiesta, e magari trasmettendo la richiesta n volte
(dove n e' calcolato per incrementare la probabilita' di ricezione da
95% a 100% con una confindenza, per dire, del 98%) si ottengono
caratteristiche simili a TCP ma con migliori prestazioni in velocita'
di ricenzione e a spese del carico di rete.
Insomma, cose cosi'. TCP e' un buon compromesso, ma se non e'
sufficiente basta attaccare ad UDP i "pezzi" che ti servono e cercare
di ottenere prestazioni migliori di TCP a spese di qualcosa che nel
contesto specifico non ti serve.