DOMANDA Socket Udp

[Nico911]

Salve, mi domandavo, ma la primitiva recv applicata su un socket UDP da in ritorno notifiche circa eventuali errori nel messaggio o lo butta semplicemente via e per l'applicazione il pacchetto non è mai arrivato?
Perché il servizio UDP si appoggia sui livelli sottostanti ed è quindi in grado di fare error detection.

 

[jax29]

UDP può fare error detection dato che l'header contiene un checksum di 16bit,
ma in caso di errore il pacchetto viene semplicemente scartato, senza inviare nulla all'applicazione.

 

[Nico911]

Ah ok grazie, però allora mi domando con quale idea in mente lo hanno sviluppato così, nel senso in TCP il protocollo può gestire in maniera molto più fine gli errori, riscontrato un errore può notificarlo al sorgente del messaggio che può rinviarlo. Il protocollo arq diciamo che oltre al packet loss sopperisce anche alla ed (ed è come ho sviluppato l'affidabilità della connessione) ma ovviamente introduce più tempi morti e duplicati quindi alla fine del discorso la mia domanda è: se con una connessione UDP dovrei avere in mano una connessione semplice ma con la quale potrei anche ricreare una connessione tcp perché non ho le stesse possibilità?(soprattutto perché basterebbe notificare un errore che riesce a riscontrare per avere effettivamente un servizio che non ha nulla da invidiare alla tcp) E come seconda domanda giusto per completezza, quindi send/recv su UDP non danno mai errori in ritorno?

 

[1nd33d]

UDP è un protocollo "fire and forget". Viene usato per applicazioni nelle quali recuperare pacchetti persi o danneggiati non importa, per esempio streaming real time, oppure quando si vuole un controllo del flusso a più alto livello.
Il TCP pur garantendo l'integrità della comunicazione, può introdurre ritardi quando singoli pacchetti sono danneggiati o mancanti, perchè TCP garantisce anche l'ordine con cui i pacchetti vengono passati ai livelli superiori. Inoltre TCP ha un overhead superiore.

 

[Nico911]

Si questo lo so, ma UDP viene anche usato per realizzare protocolli personalizzati, se appunto TCP mi da troppo ritardo perché mi fa molti controlli che nel mio ipotetico caso non sono necessari, mi posso sviluppare a livello di applicazione partendo da una connessione base(UDP) il mio servizio personalizzato che effettua i controlli solo strettamente necessari alla mia applicazione. Questo però proprio per questo motivo(non mi notifica gli error detection) lo trovo incompleto e non capisco perché se bastava così poco(inviare una notifica nella recv)

E ripeto, è vero si che posso implementare il protocollo arq e questo è in grado comunque di gestire anche gli errore detection(gestisce i packet loss e difatto in UDP ci sono solo packet loss) ma è comunque più inefficiente di quello che avrei con un recupero con ack/nak+arq come è implementato dal tcp e dato che se ho scelto UDP è per migliorare la velocità di trasmissione la trovo una cosa un po illogica

 

[jax29]

il mio servizio personalizzato che effettua i controlli solo strettamente necessari alla mia applicazione. Questo però proprio per questo motivo(non mi notifica gli error detection) lo trovo incompleto e non capisco perché se bastava così poco(inviare una notifica nella recv)

Il problema non è notificare i pacchetti che arrivano all'host di destinazione danneggiati, ma il fatto che un pacchetto può venir scartato da qualsiasi nodo della rete che collega i due host, per tanti motivi diversi.

 

[Nico911]

Forse ho capito quello che intendevi, il senso è che se il pacchetto da errore con udp verrà buttato dal primo router che lo rileva(il dest_IP non è più attendibile e non lo recupera) ed è quasi impossibile arrivi all'host un pacchetto corrotto, se arriva significherebbe che si è corrotto sul link tra l'ultimo router e il destinatario, quindi non si otterrebbero grandi vantaggi dal ripristinarlo dal destinatario rispetto ad avere un packet loss.

 

[Fedexx2]

Forse ho capito quello che intendevi, il senso è che se il pacchetto da errore con udp verrà buttato dal primo router che lo rileva(il dest_IP non è più attendibile e non lo recupera) ed è quasi impossibile arrivi all'host un pacchetto corrotto, se arriva significherebbe che si è corrotto sul link tra l'ultimo router e il destinatario, quindi non si otterrebbero grandi vantaggi dal ripristinarlo dal destinatario rispetto ad avere un packet loss.

Yess esattamente.