Ordine UDP di pacchetti con connessione diretta

Sì, è possibile.

Questo potrebbe essere dipendente dall'hardware e dal driver e potrebbe essere molto diverso a seconda di quali altri tipi di pacchetti vengono inviati sulla linea contemporaneamente.

In che modo i buffer di pacchetti interni gestiscono le richieste di invio in entrata? Non puoi saperlo Potrebbe essere utilizzare buffer paralleli che si riempiono in modi strani. Dal momento che le specifiche non hanno una garanzia, non ci sarebbe alcun motivo per l'implementatore di preoccuparsi di mantenere le cose sincronizzate (specialmente considerando i guadagni di velocità con mancanza di overhead).

Una finestra di Windows potrebbe decidere di inviare una richiesta di aggiornamento dell'ora NTP e una scansione della condivisione di rete, e quindi mentre si trova nel mezzo di essa, dropbox potrebbe fare una richiesta per le cartelle locali. Ora qualsiasi dato nei buffer è sospetto.

Potresti inviare milioni di pacchetti senza riscontrare questo problema. Ma è una possibilità. Le probabilità che ciò accada potrebbero essere piccole, ma succederà.

L'unico vero modo per garantire che questi non causino problemi è se si sta utilizzando il proprio sistema operativo e si ha una conoscenza esplicita di come funziona l'hardware e si ha il codice sorgente del driver e il codice sorgente dell'API UDP.

I pacchetti UDP non sono garantiti per arrivare in ordine. Dovresti usare TCP per questo.

Non devono per forza arrivare né in ordine.

Suppongo che tu stia sperando che questo non sia il caso a causa della semplicità del setup, ma c'è ancora un sistema di bus sottostante e cose come se i due computer tentassero di inviare allo stesso tempo possono accadere.

Ovviamente non lo farò con Ethernet commutata, ma dovrai distruggere diversi livelli di astrazione per rispondere alla tua domanda in un modo diverso da "forse no".

Sì, potrebbe essere che l'applicazione sul sistema B riceva i pacchetti UDP in un ordine diverso da quello che sono stati inviati dall'applicazione sul sistema A. Se entrambi i sistemi sono connessi allo stesso segmento di rete, la probabilità che si verifichi è piccolo, ma non sarà mai trascurabile.

Ciò che può anche accadere è che i pacchetti vengono persi, ad esempio perché c'è stata una collisione tra due pacchetti su uno switch o hub che collega i sistemi.

Nel mondo del software, ci occupiamo di certezze e di scenari statisticamente impossibili prima di decidere di utilizzare una determinata soluzione. Se i pacchetti possono / arriveranno in modo affidabile e ciò che si intende fare per gestire tale eventualità, ha tutto a che fare con l'utilizzo o meno di tale soluzione.

Comunque, no, non arriveranno in ordine (o affatto) e se lo usate, dovete affrontarlo nei vostri livelli di trasporto - come nel modo in cui lo fa RTP o qualcosa del genere.

Sebbene l'ordine o l'arrivo non siano giustificati dalle specifiche, nel tuo contesto non vedo alcun dispositivo che possa riordinare i pacchetti o distruggerli (a condizione che non sia presente altro traffico di rete).

Nel caso in cui, è possibile creare un test che viene eseguito durante un paio d'ore e che invia pacchetti con un numero di sequenza incrementale nel corpo e che non riesce non appena il numero di sequenza di un pacchetto ricevuto non corrisponde al numero di pacchetti ricevuti finora.

È possibile. Ho osservato un simile comportamento sulla connessione diretta (senza hub o switch) tra due macchine. Nel mio caso è successo solo quando un'applicazione ha inviato datagrammi uno dopo l'altro senza alcun ritardo tra di loro. In questo caso accadrebbe con alta probabilità (oltre 1/30). Dovrei notare che questo comportamento era dipendente dall'hardware: si sarebbe verificato solo su una riga specifica dei computer di Kontron. Inoltre si verificherebbe solo quando l'applicazione diventerà datagramma il più veloce possibile - dopo aver artificalmente ritardato il prossimo datagramma per 1 millisecondo, non ho potuto più osservare questo.