私は、すべての通信にソケットを使用する単純なクライアント/サーバーアプリケーションに取り組んでいます。通信はパケットベースであり、パケットの概念は、ソケットストリームのクラスおよびObjectInputStream/ObjectOutputStreamラッパーのセットを使用して実装されます。
完全にテキストベースのプロトコル（IRCなど）または明示的にバイトを操作する「非常にバイナリ」なプロトコルと比較した場合、このアプローチに不利な点があるかどうか疑問に思います。
ここではトラフィックの問題（「qwerty」と「qwerty」+ 1KBのメタデータ）を無視し、信頼性と保守性のみを考慮しましょう。
どう思いますか？
個人的には、Javaに組み込まれているバイナリシリアル化は非常に苦痛であることがわかりました。問題を引き起こすと予想されるものを何も変更していなくても、バージョンの非互換性に陥るのはばかげて簡単です。
次の場合は問題になりません。
たぶんそれはあなたの状況ですが、個人的には、バージョン管理をより柔軟に行えるシリアル化形式を好みます。もちろん、バイナリまたはテキストである必要はありません。JSON、Protocol Buffers、Thrift、またはその他のオプションをいくつでも使用できます。それぞれに長所と短所がありますが、Javaよりも単純なバージョン互換性を念頭に置いて設計されている可能性があります。
Javaシリアル化の利点は、すべてが機能する状況（ツリー全体がシリアル化可能）で、他の変更なしでシリアル化できることです。データを個別にモデル化する必要はありません。いくつかのシリアル化フレームワーク。残念ながら、ツリーのどこかでシリアル化できないクラスを使用したい場合は、すぐに苦痛に戻ります...
テキスト形式とバイナリ形式のどちらを選択するかについては、長所と短所はかなり明白です。テキストは大きくなりますが、ネットワークトレースを確認するだけで、何が起こっているのかを簡単に診断できます。もちろん、両側で同じエンコーディングを使用していることを確認する必要があります。
ああ、そしてもちろん、Java以外のクライアント/サーバーと通信したい場合、Javaのネイティブシリアル化を使用したことがあると苦労するでしょう:)
シリアル化されたオブジェクトとの後方比較可能性を維持するのは苦痛であり、Java以外のクライアントはサービスと通信できません。シリアル化されたオブジェクトは、シリアル化されたサイズに関しても優れていません。
代わりに、プロトコルバッファのようなものを使用します。