8byte(long,double)をネットワークバイトオーダーに変換することはあるのか？していいのか？

Question

やろうとしていること

C言語で構造体をtcpのソケットを用いて送受信しようとしています。
#include <sys/stat.h>で定義がされている
struct statをそのまま送りたいと考えていました。

問題点

struct statをネットワークバイトオーダー(ビッグエンディアン)に変換したいと思い、メンバ変数を一つずつ変換する処理を書いていたところでした。
struct statのメンバ変数にはmtime,atime,blksizeなどlong型に相当する変数が存在していまして、私のマシンは64bitなのでこれらの変数は8byteです。つまり、8byteのデータを送信する必要があるのでバイトオーダーの変換をしようとしましたが、
バイトオーダー変換用の関数として#include <arpa.inet.h>に含まれている関数を探すとhtonsやhtonlぐらいで2byte,4byteを変換する関数しか見つかりませんでした。自作して使っても良いのですけど、なぜ8byte用が実装されていないのでしょうか？
32bitマシンとの通信ができないからという理由もありそうですが、そうだとしたら上記のstruct statはそのまま変換せずに最大4byteに各メンバ変数を調整するべきということでしょうか？

お聞きしたいこと

なぜ8byteのバイトオーダー変換は公に実装されていないのか？（あったとしても見つからない)
そもそも32bitマシンと64bitマシンは通信することはよくあるのか？
です。

まとまっていなくて申し訳ありませんが、もしここらへんの常識を教えていただけますなら宜しくおねがいします。

Answer 1

なぜ8byteのバイトオーダー変換は公に実装されていないのか？（あったとしても見つからない)

linux限定ですが、以下の関数が提供されています。（私は使ったことはありませんので参考程度にしてください）
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/endian.3.html

そもそも32bitマシンと64bitマシンは通信することはよくあるのか？

送信元、送信先で送受信データを取り決める場合、そもそも、相手方のマシンが何ビットかを考慮する必要はありません。８バイトのデータを送られた場合、受け取った側は、３２ビットマシンであろうが、６４ビットマシンであろうが、それをきちんと処理しなければいけません。もし、受け手が処理できないなら、最初にそのような取り決めをしてはいけません。（３２ビットマシンでも８バイト整数は処置可能です。linuxならlong long int型で処理可能）
ネットワークバイトオーダーで送るのが、伝送時の決め事となっていますが、私の知っている範囲では、これを律儀に守っているのは日本の会社だけのように思われます。実際に中国の上海とか深センとかから送られてくるデータは、リトルエンディアンのデータになっているケースが多いです。（欧米からバイナリデータを受けたことはないので欧米については不明）
現実的には、送り側も受け側もインテル系のCPUなので、お互いにリトルエンディアンのほうが簡単です。
（ひと昔はSPARC系もあったのでビッグエンディアンのほうが良かったのですが・・・）
日本の会社では、律儀に、ビッグエンディアンを採用するので、送り側がリトルエンディアン→ビッグエンディアン
変換を行い、受け側が、ビッグエンディアン→リトルエンディアンを行っています。これはお互いにとって不幸なことのようにも思われます。
この辺にも規則に縛られる日本人と規則にとらわれず現実的な利益を優先する中国人との違いが表れています。
（どちらにも一長一短はありますが）
「32bitマシンと64bitマシンは通信することはよくあるのか」の対する直接的な答えは、「よくあるが、相手方のマシンのBitサイズを意識する必要はない」になります。

Comments

[yonde]

ご回答有り難うございます。
私の場合、送受信側でデータ形式は取り決めるつもりでしたので、確かに一般的な慣習に無理に合わせる必要もないということはよく理解できました。
バイトオーダーに関する現代の環境についてもご指導いただきありがとうございます。

Answer 2

8 byte 用がないということはなくて、Windows と macOS なら htonll() ntohll()、Linux なら htobe64() be64toh() があります。

8 byte のバイナリの値を送受信するメジャーなプロトコルは思い当たりませんが、もちろんそういうプロトコルを定義しても構いません。主流はバイナリよりはテキスト化して送受信することな気がします。

Comments

[yonde]

ご回答有り難うございます。
環境別に関数があることを知りませんでした。
テキスト化して送受信するとなるとJSON形式で表現してシリアライズするのも良いですね。

Answer 3

結局は送信側と受信側で解釈が一致していればよいのであなたがプロトコルに関する裁量を持っていて送信側も受信側も作るのであればどう実装しようと自由です。 習慣的にネットワーク上のデータの流通にはネットワークバイトオーダ (ビッグエンディアン) を使うことになっていますが、リトルエンディアンで統一するのであればそれでも問題ありません。

64bit 版のバイトオーダ変換関数がある環境もありますが、無い場合もありますし、あったとしても名前や使い方が異なったりもします。 そういった違いは configure で吸収するのですが……「64bit 用のバイトオーダ変換関数がその環境にあればそれを使って無ければ自分で定義したものを使う」などとするよりは常に自分で定義してしまったほうがてっとり早いです。

現代では構造体 (などの各プログラミング言語におけるデータ表現) をバイト列に対応付けるのは既存のシリアライザを導入する方法が好まれ、 Protocol Buffers がよく用いられるようです。 つまり、変換を自分で書くという状況自体を避けるということです。

Comments

[yonde]

ご回答有り難うございます。
grpcを用いた構造体の送受信も考えていたのですが、やろうとしていることの割には高機能でビルドが大変そうで敬遠していました。
この期にもう一度腰を据えて試してみようと思います。