2012-09-20 9 views
12

Sto solo ripulendo un po 'di codice che abbiamo scritto un po' indietro e ho notato che per un socket udp, 0 viene considerato come la connessione chiusa.Sotto Linux, può recv restituire sempre 0 su UDP?

Sono abbastanza sicuro che questo era il risultato del porting dello stesso ciclo di ricv dalla versione tcp equivalente. Ma mi fa meravigliare. Può recv restituire 0 per udp? su tcp segnala che l'altra estremità ha chiuso la connessione. udp non ha il concetto di una connessione, quindi può restituire 0? e se può, qual è il suo significato?

Nota: la pagina man in linux non distingue udp e tcp per un codice di ritorno pari a zero che potrebbe essere il motivo per cui abbiamo mantenuto il controllo nel codice.

+0

Le prese UDP sono collegate o no? –

+0

È possibile chiamare "connect" sui socket UDP, ma tutto ciò è assegnare un indirizzo/porta IP remoto al socket UDP. Ciò consente di chiamare solo "send" e "recv" senza sendto, recvfrom. Credo che funzioni anche come filtro e ti consente di ricevere solo i datagrammi di udp da quell'indirizzo. Quindi in un certo senso sono connessi, ma non come con il TCP. – Matt

risposta

12

udp non ha il concetto di connessione, quindi può restituire 0? e se possibile, che cosa si intende

Significa che è stato ricevuto un datagramma di lunghezza 0. Dal grande UNP:

Scrivere un datagramma di lunghezza 0 è accettabile. Nel caso di UDP, questo genera un datagramma IP che contiene un'intestazione IP (normalmente 20 byte per IPv4 e 40 byte per IPv6), un'intestazione UDP a 8 byte e nessun dato. Ciò significa anche che un valore di ritorno 0 da recvfrom è accettabile per un protocollo datagramma: Ciò non significa che il peer ha chiuso la connessione , così come un valore di ritorno di 0 da leggere su un socket TCP. Poiché UDP non è connesso, non esiste una chiusura della connessione UDP .

+0

Non ricordo che un datagramma garantito sia consegnato o non diversamente da tcp dove puoi ricevere alcuni dati. –

+0

@AdrianCornish Penso che tutti gli stack moderni provano a consegnarlo anche se non c'è payload. – cnicutar

+0

È stata interrotta in modo errato quella domanda, ad esempio potevo inviare 100 byte su una connessione TCP e l'altra estremità poteva solo ottenerne 50 e bisognava leggerla di nuovo, quindi suppongo che la vera domanda possa essere frammentata a livello di applicazione –

Problemi correlati