Posso tranquillamente ignorare l'ordine dei byte nella rete?

... why would I rearrange the bytes ... when I already know that both, server and client run on little endian? Thats just unnecessary work to do.

È inutile solo se puoi garantire che il tuo codice funzioni sempre su architetture little-endian. Se hai intenzione di avere una lunga vita, vale la pena di evitare di disturbare un codice ben collaudato da un decennio a partire da quando alcune architetture big-endiane sono diventate la cosa "in" e trovi che sia un buon mercato per la tua applicazione.

Esiste un ordinamento di byte standard di rete. È big-endian, ma nulla dice che devi rispettarlo durante la progettazione del tuo protocollo. Se sapete in anticipo la maggior parte dei sistemi che eseguono il vostro codice saranno little-endian e le prestazioni sono critiche, dichiarate che il "tkausl standard order order" e seguitelo. Dove normalmente chiameresti htons() per mettere le cose nell'ordine che ti serve, scrivi una macro chiamata htots() che non compila in modo condizionale su architetture little-endian e fa la riorganizzazione su big-endian.

Mantenere il codice per effettuare le conversioni in entrata e in uscita non è davvero un grande sforzo. Se hai un numero molto elevato di messaggi, trova un modo per esprimerli e scrivi un programma per generare le conversioni in entrata e in uscita.

È il tuo protocollo.

Non puoi ignorarlo tranquillamente. Ma puoi tranquillamente etichettarlo. Tu controlli il client e il server. Tu controlli il protocollo. Non ha senso non preoccuparsi se è big-endian o little-endian fintanto che sai se entrambe le parti sono d'accordo?

Questo significa overhead. Ora devi segnare il tuo endianness in qualche modo. Fallo e io posso leggerlo su qualsiasi cosa.

Se non vuoi sovraccaricare i dati e la tua CPU è annoiata e cerca qualcosa da fare, allora conform .

So, my question is: Can I safely ignore the endianess and just send little-endian data?

Ci sono due interpretazioni di questo:

• Se progetti le tue applicazioni / i protocolli per sempre ¹ invia little-endian, allora NON stai ignorando endianess.

• Se progetti le tue applicazioni / i protocolli per inviare / ricevere qualunque sia l'endianess nativa, allora funzioneranno fintanto che eseguirai le tue applicazioni su piattaforme con la stessa endianess nativa.

  È "sicuro" ² ? Questo è per te da giudicare! Ma certamente ci sono piattaforme hardware comuni che usano little-endian, big-endian o ... bi-endian.

  Riferimento:

  • link

What are the disadvantages?

L'ovvio svantaggio derivante dall'ignorare l'endianess è che se i tuoi utenti devono eseguire le tue applicazioni / protocolli tra piattaforme con endianess nativi diversi, allora hai un problema. Le applicazioni si interromperanno e sarà necessario cambiarle per risolvere il problema. E affrontare i problemi di compatibilità delle versioni, eccetera.

Chiaramente, la maggior parte delle piattaforme di generazione corrente sono nativamente poco endian, ma 1) altre no, e 2) possiamo solo immaginare che cosa accadrà in futuro.

^{1 - Sempre ... anche su piattaforme che sono nativamente big-endian.}

^{2 - In effetti, che cosa significa "sicuro"? Se ci stai chiedendo di prevedere la direzione futura delle piattaforme hardware ... temo che non sia obiettivamente rispondente.}

L'endianità non è l'unica considerazione. C'è la dimensione dei numeri interi, ci sono pacchetti di strutture che potresti voler inviare o ricevere e così via.

Puoi ignorare tutto questo. Nessuno può forzarti. D'altra parte, il modo sicuro e affidabile consiste nel documentare un formato esterno e quindi scrivere codice che legge o scrive correttamente il formato esterno, indipendentemente dal processore, dal linguaggio di programmazione e dall'implementazione del linguaggio di programmazione.

Di solito non è molto codice. Ma ha un enorme vantaggio: le persone che leggono il tuo codice non sospetteranno che tu sia incapace di capire, non sappia nulla sullo scambio di dati esterni e scriva codice che generalmente non può essere considerato attendibile.

Lo stack di rete BSD standard in C ha la funzionalità hton / ntoh ( network-to-host / host-to-network ) che si espande in no-op su macchine native della rete (big endian). Avresti bisogno delle tue controparti per lo scenario in cui l'ordine dei byte nativi della rete è little endian.

Questo è il modo più efficace per farlo.

Sarebbe non convenzionale, ma non vedo nulla di sbagliato in questo. I computer collegati in rete ottengono sempre i bytest e devono concordare i protocolli su come interpretarli. Questo è solo parte di esso.

Diversi protocolli utilizzati per trasmettere dati tra server utilizzano numeri little endian:

1. BSON
2. Buffer del protocollo
3. Capn Proto

Vedi link , per i dettagli su vari formati alcuni dei quali hanno numeri little-endian, e alcuni hanno big-endian numeri.

Non c'è assolutamente niente di sbagliato nell'usare un protocollo basato su numeri little endian. Una grande macchina endian è in grado di leggere piccoli numeri endianiani come una piccola macchina endianista in grado di leggere numeri big endian. Molte persone lo hanno fatto specificamente per evitare il costo extra di calcolo della decodifica dei numeri big-endian su macchine little endian.

Se costruisci il tuo protocollo su uno di questi protocolli esistenti, non devi nemmeno preoccuparti del problema, che è già stato risolto. Quando decidi di eseguire il tuo codice su una piattaforma big-endian, le librerie che implementano questi protocolli si prenderanno automaticamente cura di decodificare i valori correttamente.

Un esempio di un sistema big endian è il MIPS usato nei router. Sia ARM che MIPS sono commutabili tramite endian, ma spesso MIPS è big endian perché rende più semplice l'hardware di rete (la parte più significativa di una parola è la parte che si riceve per prima e può prendere una decisione di routing prima di aver ricevuto il resto di la parola, piuttosto che dover bufferizzare l'intera parola).

Quindi dipende da cosa intendi con 'Linux', ma se vuoi eseguire l'app del tuo server su un sistema più piccolo come un router che esegue OpenWRT, potresti dover considerare il supporto di big endian.

Come al solito, semplificare le ipotesi è un'ottimizzazione perfettamente ragionevole fino al momento in cui si colpisce qualcosa che non si adatta alle ipotesi. Solo tu puoi dire quanto sarebbe doloroso rilassarsi se ti imbatterai in un simile problema.

Non penso che nessuna delle risposte sia abbastanza precisa. Secondo Wikipedia endianness è l'ordine dei byte che comprendono una parola.

Prendiamo 4 byte e li interpretiamo come int. Un sistema little endian i byte saranno interpretati da destra a sinistra e vice-verca su un sistema big endian. Ovviamente è importante concordare su quale fine interpretare un int.

Consente di ridurre leggermente i protocolli di rete moderni che potrebbero utilizzare json o xml. Nessuno di questi formati trasferirà un int come 4 byte. Trasferiranno i dati come testo che verrà analizzato come int sul lato ricevente.

Quindi alla fine endianness non importa quando si usa json o xml. Abbiamo ancora bisogno di usare big endian per le intestazioni di tcp, motivo per cui è chiamato ordine di byte di rete, ma la maggior parte dei programmatori non ha bisogno di fare confusione con quelli su base giornaliera.

La codifica più utilizzata per lo più oggi è utf-8 che può anche essere immune ai problemi riguardanti l'endianness .

Quindi direi di si. Ignorare endianness è sicuro quando si utilizzano formati basati su testo trasferiti usando utf-8.

I sistemi big endian sembrano essere in via di estinzione. Molti degli unix tradizionali utilizzavano big endian ma sono in declino da anni a favore di linux su x86.

arm è bi-endian ma la variante big endian sembra essere vista raramente.

mips esiste in entrambe le varianti. Afaict la variante big endian si vede principalmente sulle applicazioni di networking (per ragioni storiche i protocolli internet generalmente usano big endian).

ppc era tradizionalmente big endian con alcune parti che supportano entrambi gli endian ma IBM sembra ora spingere la modalità little endian per ppc a 64 bit (recentemente hanno spinto le porte di ppc64el in Debian e Ubuntu).

sparc è normalmente big endian ma sembra di nuovo in declino.

Se stai implementando un protocollo esistente, ovviamente devi seguire le sue specifiche. Se vuoi che l'IETF benedica il tuo nuovo protocollo, allora big endian sarà probabilmente più facile perché è quello che usano già nei loro protocolli esistenti, ma IMO per un nuovo design di protocoll "greenfield" little endian è la strada da percorrere.

È possibile inserire macro all'inizio, che saranno non operative su sistemi little endian o non si può disturbare fino a / a meno che non sia necessario effettuare il porting su un sistema big endian.