DatagramPacket . Ricevere file testuale da 16KB

[lionell88]

Salve .
Ho un programma che deve ricevere , tramite collegamento UDP , un file di testo di max 16kb (quindi una stringa da 16384 byte ) .
Sappiamo che nel mio datagramPacket per l'ingresso dei dati devo passare un buffer . Questo buffer deve essere grande 16384 byte ?
Oppure c'è altro modo per realizzare la cosa ?

[MdE2005]

Originariamente inviato da lionell88
Oppure c'è altro modo per realizzare la cosa ?

In generale quando si parla di protocollo di comunicazione, sia TCP/IP che UDP, si parla anche di correttezza dei dati inviati e ricevuti, è alla base di ogni comunicazione.
Sebbene per piccole quantità di dati la probabilità di ricevere dati non corretti o non riceverli sia estremamente bassa, è buona regola implementare un proprio algoritmo, come ho già spiegato in questa discussione

http://forum.html.it/forum/showthrea...readid=1432220


E' riferita a VB.NET e a TCP/IP ma i concetti non cambiano.


Ciao

[lionell88]

Quello che dici tu lo penso pure io visto che ho appena dato un esame di reti di TLC
Il mio problema (essendo una "new entry" nel mondo java) riguarda l'utilizzo dells classe DatagramPacket.
So che per i dati in entrata devo creare ad es

...
DatagramPacket packet = new DatagramPacket(buffer,buffer.length);
...

Non capisco come stabilire la lunghezza del buffer !
Io di solito , faccio

byte[] buffer = new byte[256]

ma se io devo ricevere una stringa di 16 Kb (il client mi sta inviando una stringa di 16kB) , il buffer può essere grande 256 byte ?

Questo lo chiedo perché non so come Java gestisce il protocollo UDP . Non so se la mia richiesta è chiara! O.o

[andbin]

Originariamente inviato da lionell88
ma se io devo ricevere una stringa di 16 Kb (il client mi sta inviando una stringa di 16kB) , il buffer può essere grande 256 byte ?

No, deve essere della lunghezza massima che ti aspetti.

Quando leggi un "pacchetto" lo fai con il

void receive(DatagramPacket p)

di DatagramSocket e la documentazione di questo metodo dice:

When this method returns, the DatagramPacket's buffer is filled with the data received.

Tradotto: vuol dire che devi passare un DatagramPacket con un buffer sufficientemente capiente per quello che ti aspetti di ricevere, il receive si limita solo a riempire questo buffer, non istanzia/alloca nulla di nuovo o più grande.

Nel caso non fosse sufficiente, dice anche:

If the message is longer than the packet's length, the message is truncated.

Tradotto: se ricevi di più di quanto il buffer può contenere, il "messaggio" è troncato, nel buffer c'è solo la porzione che ci sta e il resto è buttato via.

[lionell88]

... e se volessi ricevere un flusso continuo di byte ad es streaming audio/video ? Non potrei più procedere in questo modo , perché il buffer diventerebbe illimitato.
So che per le comunicazioni in realtime viene usato il protocollo RTP che è basato su UDP ... se volessi usare direttamente UDP , a questo punto suppongo di dovermi creare un mio protocollo , ma credo che non mi convenga !

[andbin]

Originariamente inviato da lionell88
... e se volessi ricevere un flusso continuo di byte ad es streaming audio/video ? Non potrei più procedere in questo modo , perché il buffer diventerebbe illimitato.

No, c'è una lunghezza massima intrinseca per un pacchetto UDP. Vedi:

http://en.wikipedia.org/wiki/User_Datagram_Protocol

dove parla del "Length".

Quindi il punto è che devi usare più pacchetti!

Originariamente inviato da lionell88
So che per le comunicazioni in realtime viene usato il protocollo RTP che è basato su UDP ... se volessi usare direttamente UDP , a questo punto suppongo di dovermi creare un mio protocollo , ma credo che non mi convenga !

Il secondo punto (conseguente) è che .... se usi più pacchetti che rappresentano un flusso logico di dati, dovresti "taggarli" affinché contengano informazioni che permettano al ricevente di capire la sequenza "logica" dei pacchetti. Ma questo lo dovresti fare tu. Che poi è più o meno proprio come fa (in modo più complesso/completo) il TCP.

I sistemi di streaming audio/video usano tipicamente UDP perché è più rapido e poi comunque se si perde qualche pacchetto .... vabbè pazienza. Insomma ... è accettabile (cioè: è una cosa che si accetta implicitamente) Non è come il download di file dove chiaramente NON deve perdersi nulla (altrimenti ovvio, è corrotto). Se di un audio non senti 5 millisecondi .... vabbè ...

[lionell88]

Quindi in java , quando il client invia un DatagramPacket , viene inviato un solo segmento UDP(lungo al massimo 2^16 byte) ... in TCP questo non lo vediamo. Infatti ,quando usiamo un socket TCP in java , non stabiliamo una dimensione per il pacchetto in ingresso o in uscita... è corretto quello che dico ?

[andbin]

Originariamente inviato da lionell88
Quindi in java , quando il client invia un DatagramPacket , viene inviato un solo segmento UDP(lungo al massimo 2^16 byte) ...

La cosa comunque vale in generale (non centra Java di per sé). Un pacchetto IP può essere lungo al massimo 65535 byte (2^16-1). E il pacchetto UDP sta dentro il pacchetto IP.
Quindi la lunghezza massima del "payload" (i dati effettivi) per UDP è la lunghezza massima (65535) a cui devi togliere l'header UDP e l'header IP.

Originariamente inviato da lionell88
in TCP questo non lo vediamo. Infatti ,quando usiamo un socket TCP in java , non stabiliamo una dimensione per il pacchetto in ingresso o in uscita... è corretto quello che dico ?

Questo perché con TCP tu gestisci un "flusso" continuo di dati (in Java sono gli Input/OutputStream di un Socket) e ci pensa lo strato TCP a gestire la pacchettizzazione in pacchetti IP, con tutto quello che riguarda la gestione di acknowledge, errori, timeout, ritrasmissioni, riordinamenti dei pacchetti.

[mxa]

Non so di preciso cosa tu voglia fare, ma se hai bisogno di un meccanismo TCP-like sopra UDP esistono delle cose gia' fatte.

Ad esempio RUDP: http://en.wikipedia.org/wiki/Reliabl...agram_Protocol o anche SCTP http://en.wikipedia.org/wiki/Stream_...ssion_Protocol e SCPS (http://www.openchannelsoftware.com/projects/SCPS).