Newsgroup: it.comp.java
Titolo: comunicazione datagram

Come posso avere riscontro dei datagram spediti, in modo da rendere un pò
più affidabile la comunicazione? Vorrei che il server in particolare si
accorgesse dei messaggi mancanti da un certo Client.
Ovviamente usando le classi DatagramPacket e DatagramSocket.

 wrote in
news:a2m08b$e1n$
1...@pegasus.tiscalinet.it
: 

Per definizione, se usi UDP, la logica di controllo e' responsabilita'
dell'applicazione. Ci sono parecchi algoritmi piu' o meno sofisticati ,
in genere basati su tecniche di ack/retry o polling, e con proprieta'
statistiche piu' o meno interessanti/costose. Una buona discussione
generale la trovi in [Tanenbaum, Andrew S., Computer Networks, 3. ed,
Prentice Hall]. 
Esiste un riscontro ack-based collaudato, portabile e interoperabile e
per cui ci sono implementazioni efficientissime: TCP. ;-) 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 statistiche piu' o meno interessanti/costose.
Ok potresti darmi un esempio semplice anche a grandi linee, oppure un link.

 wrote in message
news:a2m08b$e1n$1...@pegasus.tiscalinet.it...

mmm .. un metodo semplicissimo è quello di numerare i pacchetti che il
server invia al client .... cioè il Client si tiene un contatore che
contiene il numero di pacchetti ricevuti e il server avrà un contatore che
contiene il numero di pacchetti inviati.Ad ogni pacchetto UDP il server
invia nella parte dei dati anche il suo contatore.Il Client ricevendo un
pacchetto confronta il suo contatore con il contatore del server (contenuto
dentro il datagramma) e se non coincidono vuol dire che qualcosa non è
andato.Il Client a questo punto potrebbe mandare un pacchetto UDP al server
contenente il suo contatore e il server può così rispedire i pacchetti
mancanti.
Un piccolo neo in questo sistema è che per definizione il protocollo UDP non
garantisce che i pacchetti arrivino nello stesso ordine in cui vengano
spediti ..però se il server non invia troppi pacchetti di seguito dovrebbe
funzionare ..con qualche accorgimento però potresti risolvere anche questo
inconveniente ...spero almeno di averti dato una idea
Ciao ciao
Dani
--
Daniele Piras
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If at first the idea is not absurd then there is no hope for it. - Albert
Einstein
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

'ca miseria .. dalla fretta non mi ero accorto che il tuo problema fosse il
riscontro da parte del SERVER devi messaggi che spedisce il CLIENT e non il
contrario ..... comunque il mio discorso è sempre valido .. basta invertire
le parti :)


 link. 
Per avere algoritmi discussi seriamente, devi guardare in letteratura -
non e' cosa che si fa in due minuti. Un'idea ovvia e' che il server
numeri i pacchetti con una codifica monotona (o periodica di periodo
sufficientemente grande) e dipendente dal client: il client conosce
l'algoritmo di codifica e mantiene un registro dei pacchetti che si
aspetta in una certa finestra di tempo, e se un certo pacchetto non e'
arrivato entro un certo tempo, invia al server una richiesta di
rispedizione, riaggiungendo il codice del pacchetto in questione al
registro di attesa. 
Il protocollo iniziale (per cui il client *viene a sapere* che una
trasmissione e' in corso) e' un semplice start-ack-confirm:il server
invia un pacchetto di start, attende un ack e reinvia se non arriva in un
certo tempo; il client invia l'ack e attende un confirm - rinviando l'ack
se il confirm non arriva in un certo tempo. Dopodiche' comincia ad
aspettarsi pacchetti. 
I dettagli e le variazioni sono infiniti (tutto sono tranne che esperto
di internetworking :-) - come dicevo, se vuoi fare qualcosa di
minimamente serio, mi sa che ti tocca studiare. 




Appoggiati a qualche pacchetto esistente: personalmente ti consiglio LRMP (Lightweight
Reliable Multicast Protocol) della INRIA:
http://webcanal.inria.fr/lrmp/index.html
Ciao,
    Bruno.
---
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola