問題タブ [bytebuffer]

複数のクライアントでボールを同時に (リアルタイムで) 動かすことに関する、NIO を使用したリアルタイムの物理シミュレーションを設計しました。

現在、文字列解析で 1 つのボールの座標を送信していますが、複数のボールを移動し、文字列を送信する以外の一般的なメカニズムが必要なため、サーバーに 4 つのボールを作成します。

各ボールの座標がクライアント上の同じボール (私もクライアント上で作成したもの) に対応し、サーバーから受け取った座標に従って各ボールを移動できることをどのように実現できるか。

これは、各ボールの参照を送信することで実現する必要がありますが、Java バイト バッファと NIO 全体でそれを実現する方法がわかりません。

私は実装に問題があります。誰かがコード例で私を助けてくれれば、それは素晴らしいでしょう。とにかく、文字列以外のオブジェクト座標などのシミュレーションデータを送信するための一般的なものは許容できます(誰かが同様の作業をした場合)が、実装する必要があります私が説明したユースケース。

ありがとう、

ジビララ

PS :反対票を投じる質問の理由を教えてください。

にallocate()またはにallocateDirect()、それが問題です。

DirectByteBufferここ数年、 s は OS レベルでの直接メモリ マッピングであるため、get/put 呼び出しの方が s よりも高速に実行されるという考えに固執してきましたHeapByteBuffer。今まで、状況に関する正確な詳細を知ることにあまり興味がありませんでした。ByteBuffer2 種類のs のどちらが速く、どのような条件であるかを知りたいです。

Websockets クライアントとサーバーを作成しようとしています。最初の接続は HTTP であり、Websockets ハンドシェイクは HTTP ヘッダーを使用して、接続で新しいプロトコルへのアップグレードが必要であることを示します。

SocketChannel から HTTP ヘッダーのセットを読み込み、アップグレードが示されている場合は、Websocket を処理する別のライブラリに切り替え、その時点から SocketChannel ストリームをまったく異なる方法で処理します (行ではなくフレームのセットとして)。 \r\n で区切ります。

任意のバイト数を ByteBuffer に読み込むことができることはわかっていますが、ハンドシェイクで Websockets フレームが送信された可能性があり、これらのコード セクション間で半分消費されたバッファーを渡したくありません。私が望むのは、シーケンス「\r\n\r\n」までのデータのみをソケットから読み取ることです。それを超えるデータは、SocketChannel オブジェクトの入力ストリームに残しておきます。

これを行うための推奨される方法は何ですか? SocketChannel から入力ストリームを取得し、バッファリングされたリーダーでラップしますか? これは、NIO、特にノンブロッキングの使用と適切に相互作用しますか? 空白行が検出されたら、バッファリングされたリーダーを入力ストリームから削除し、チャネルが Websockets コードに渡されたときにすべてのフレーム データを利用できるようにすることはできますか?

または、バイトごとに (または、ターゲットの "\r\n\r\n" 文字の一部がチャンクの最後に表示される場合は、バッファーが小さい 4 バイトのチャンク) を読み取り、ヘッダー文字列を構築する必要があるかもしれません。仕方。

あるいは、バッファが直接割り当てられていれば、mark、limit、および position の操作の組み合わせによって、入力ストリームが以前に ByteBuffer に読み取ったデータを取り戻すことができるかもしれません。

アドバイスをいただければ幸いです。

私はメモリを大量に消費するアプリケーションを支援するオプションを模索しており、そうすることでTerracottaのBigMemoryに出くわしました。私が収集したものから、彼らはガベージコレクションされていないオフヒープの「ネイティブメモリ」を利用しており、シリアル化/逆シリアル化の問題により、これはヒープストレージよりも約10倍遅いようです。BigMemoryについて読む前は、通常のJNI以外の「ネイティブメモリ」について聞いたことがありませんでした。BigMemoryは、さらに検討する必要のある興味深いオプションですが、シリアル化の問題を回避できれば、ネイティブメモリで何ができるのか興味があります。

ByteBufferシリアル化の問題がない場合（たとえば、巨大なものと比較している場合）、Javaネイティブメモリは従来のヒープメモリよりも高速ですか（これにはオブジェクトが必要だと思いますか？ byte[]）？それとも、ガベージコレクションなどの気まぐれがこの質問に答えられないようにしますか？「測定する」がこのあたりの一般的な答えであることは知っていますが、Javaでネイティブメモリがどのように機能するかについてはまだ十分にわかっていないため、代表的なテストを設定しないのではないかと思います。

OpenGL でレンダリングするための頂点と要素を含むメモリ マップト ファイルを読み込もうとしています。ファイルは iPhone アプリに正しく読み込まれますが、Android で同じことを行う方法がわかりません。私は ByteBuffer、FloatBuffer、および IntBuffer と格闘してきましたが、それらの動作の 1 つの側面に困惑しています。

次のコードは、長さの読み取り、頂点データの FloatBuffer の設定、頂点データの後に来る別の長さの読み取り、要素データの ShortBuffer の設定を試みます。

ドキュメントの私の解釈に基づいて、asIntBuffer呼び出しは、現在の位置から始まり、バッファーの最後までのバイトにバッファーを返す必要があります。つまり、 を呼び出してスキップした頂点データを無視する必要がありdata.position(data.position() + lenVerts)ます。

問題は、これを実行していないように見えることです。に渡す値に関係なく、 へdata.position(...)の呼び出しはasIntBuffer常に、基になる ByteBuffer 全体にバッファーを返します。lenVerts == lenElemsこれは、 (つまり、頂点と要素のデータのサイズが異なっていても、同じ値が 2 回読み取られる) ということと、data.capacity() == 4*ib.capacity()(つまり、ByteBuffer には、IntBuffer が持つ整数の 4 倍のバイトがある) という点に注意することによって、二重に確認されます。 .

私は何か間違ったことをしていますか？ドキュメントを間違って解釈しましたか?

基礎となる ByteBuffer の一部のみによってサポートされる XxxBuffer を作成するにはどうすればよいですか?

java.nio.ByteBuffer aを（新しく作成された）CharBuffer bまたはに変換する最速の方法は何ですかchar[] b。

これを行うことにより、それが重要ですa[i] == b[i]。これは、一緒に値を構成するのではなくa[i]、a[i+1]何b[j]をするかを意味getChar(i)しますが、値は「拡散」する必要があります。

byte:-128と同じ（下位8）ビットがあることに注意してくださいchar:128。したがって、ビットが同じであるため、「最良の」解釈は上記のとおりであると思います。

その後、その逆char[]の翻訳も必要です。 またはjava.nio.CharBufferをに戻す最も効率的な方法java.nio.ByteBufferです。

こんにちは、誰かがこの問題を解決するのを手伝ってくれることを願っています..

私の観点からは、ここにコードセクションがあってはならないのに、なぜこのランタイムエラーが発生するのか興味があります:

プログラムを実行すると、次のように表示されます。

これは、LU62XnsCvr クラス内での参照の前に宣言された整数変数 MGBUFLN です。

これは、LU62XnsCvr クラスのメンバー変数として宣言された「ソース」として使用されるバイト配列です...

これは、Oracle Java Doc Web サイトからコピーしたものです。どのくらい最新かは正確にはわかりませんが、
Java 6 としてマークされており、Java 1.6 を使用する IBM の SDK を実行しています。

public ByteBuffer put(byte[] src, int オフセット, int 長さ)

相対一括プット方式 (オプション操作)。このメソッドは、指定されたソース配列からこのバッファーにバイトを転送します。配列からコピーするバイト数が、このバッファーに残っているバイト数よりも多い場合 (つまり、長さ > 残り ()) の場合、バイトは転送されず、BufferOverflowException がスローされます。それ以外の場合、このメソッドは、配列内の指定されたオフセットおよびこのバッファーの現在位置から開始して、指定された配列からこのバッファーに length バイトをコピーします。次に、このバッファーの位置が長さだけインクリメントされます。つまり、この形式のメソッドの呼び出しはdst.put(src, off, len)、ループとまったく同じ効果があります。

ただし、最初にこのバッファーに十分なスペースがあることを確認し、はるかに効率的である可能性があります。

パラメーター：

• src - バイトが読み取られる配列
• offset - 読み取られる最初のバイトの配列内のオフセット。負でなく、array.length 以下でなければなりません
• length - 指定された配列から読み取るバイト数。負ではなく、array.length - オフセット以下でなければなりません

戻り値: このバッファ

スロー:

• BufferOverflowException - このバッファーに十分なスペースがない場合
• IndexOutOfBoundsException - オフセットおよび長さパラメーターの前提条件が満たされていない場合
• ReadOnlyBufferException - このバッファが読み取り専用の場合

私は次のステートメントに少し関心があります。

それ以外の場合、このメソッドは、配列内の指定されたオフセットおよびこのバッファーの現在位置から開始して、指定された配列からこのバッファーに length バイトをコピーします。次に、このバッファーの位置が長さだけインクリメントされます。

その後：

ただし、最初にこのバッファーに十分なスペースがあることを確認し、はるかに効率的である可能性があります。

// * 私の追加コメント * //

ここで、192バイトのバッファを完全に「埋める」必要があります（インデックスは0〜191の範囲です）したがって、ドキュメントに記載されているように、バッファは長さ （この場合は192バイト）
だけ「増加」します

次に、「ロジック」がインデックスに192バイトを追加し
、見よ...インデックスの範囲外にあることを暗示しているように私には思えます...

これについて誰かの意見をいただければ幸いです。
コメントや提案を待っています...

ありがとう

男

Javaでテキストファイルを連結するために思いついた2つの方法のうち、どちらが優れているかを知りたいと思います。FileChannelへのこれらの書き込み方法の違いを説明するカーネルレベルで何が起こっているかについて誰かが共有できる洞察を持っているなら、私はそれを大いに感謝します。

ドキュメントやその他のStackOverflowの会話から私が理解していることから、allocateDirectはドライブにスペースを割り当て、ほとんどの場合RAMの使用を回避します。ファイルのファイルが大きい場合、たとえば1GBの場合、allocateDirectで作成されたByteBufferがオーバーフローしたり、割り当てられなかったりする可能性があるのではないかと心配しています。ソフトウェア開発のこの時点で、ファイルは2GB以下であることが保証されています。ただし、将来的には10GBまたは20GBになる可能性があります。

transferFromループがループを2回以上通過することはないことを確認しました...したがって、infile全体を一度に書き込むことに成功したようです。しかし、60MBを超えるファイルではテストしていません。ただし、ドキュメントには一度に書き込まれる量の保証がないと指定されているため、ループしました。transferFromは、私のシステムでは、カウントパラメータとしてint32しか受け入れることができないため、一度に2GBを超える転送を指定することはできません...繰り返しになりますが、カーネルの専門知識が理解に役立ちます。

よろしくお願いします!!

ByteBufferの使用：

trasferTo（またはtransferFrom）の使用：

こんにちは、私は Java でダイレクト バッファを使用しています。高速な memcopy が必要です。C には memcpy コマンドがあり、Java 配列には Arrays.copyOf があります。しかし、直接バッファーの代わりに配列を使用する方法はありません。それらを OpenGL に転送する必要があるからです。

ByteBuffer を使用して Java nio でデータを転送しています。同じメッセージを複数の受信者に送信できます。メッセージのフォーマットは「メッセージヘッダー＋メッセージ内容」です。簡単な方法は、各レシーバーに新しいバイト バッファーを割り当てることです。これは効率的ではありません。

私の質問は、C/C++ で ByteBuffer からポインター関数への同様の Java 関数があるかどうかです。したがって、1 つのバッファーを使用してメッセージの内容を保持し、さまざまなヘッダーと連結できます。このように効率化です。

ありがとう。