2

私はCamel、Netty、およびUDPを初めて使用しますが、これについてしばらく調査してきましたが、何が起こっているのかまだわかりません。

私がやろうとしているのは、Camel と Netty を使用して UDP リスナーを実装することだけです (現在は Windows 7 ですが、プロジェクトを Linux に移行する予定です)。私の春の設定は次のとおりです。

<camel:camelContext id="test">
    <camel:route>
        <camel:from uri="netty:udp://localhost:5150?sync=false"/>
        <camel:to uri="log:cameltest?level=DEBUG"/>     
        <camel:to uri="file://outbox"/>
    </camel:route>
</camel:camelContext>

リスナーは正常に起動しているように見えます (Eclipse を介して実行されます)。ただし、netstat を実行すると、次のように表示されます。

UDP    0.0.0.0:5150
UDP    [::ffff:127.0.0.1]:5150

127.0.0.1でリッスンしていると予想しているとき。これがCamel/Netty/UDPの予想される動作であるかどうかについて、私がオンラインで読んだものは明確ではありません。

Java NIO UDP クライアントから送信して、これをテストしています。NIO UDP サーバーがリッスンしている場合、正常にパケットを受信します (すべて localhost を介して行われます)。

Camel/Netty/TCP リスナーもテストしましたが、問題なく動作します。

リスナーがすべてのローカル アドレスをリッスンしているのはなぜですか? もしそうなら、なぜlocalhostから私のパケットを受信して​​いないのですか?

4

1 に答える 1

8

私はそれを考え出した。これは私の最後の春のコンテキストでした:

<bean class="org.jboss.netty.handler.codec.string.StringDecoder" id="stringDecoder">
    <constructor-arg value="ISO_8859_1" />
</bean>

<camel:camelContext id="test">
    <camel:route>
        <camel:from uri="netty:udp://localhost:5150?decoder=#stringDecoder&amp;disconnectOnNoReply=false&amp;sync=false"/>
        <camel:to uri="log:cameltest?level=DEBUG"/>     
        <camel:to uri="file://outbox"/>
    </camel:route>
</camel:camelContext>

UDP と Netty について調査した結果、0.0.0.0:[port#] でリッスンすることが Netty/UDP のデフォルトの動作であることがわかりました。0.0.0.0 の意味の詳細については、このリンクを参照してください

仲間のプログラマーが (私は基本的にフレームワーク内のフレームワークで作業しているため)、ラクダのものを取り出して Netty で動作させることを提案しました。これを試してみたところ、動作するようになり、NIO UDP クライアントから送信することもできました。Netty の実装に問題が見られなかったので、しばらくの間、問題は camel にあると考えていました。

Netty/UDP、Camel/TCP、および「壊れた」Camel/UDP で何時間も段階的なデバッグを行った後、Camel Netty の実装がパッケージの を使用して接続をバインドしていることに気付きましConnectionlessBootstraporg.jboss。私の Netty 実装では、パッケージBootstrapから使用していました。io.netty

http://massapi.com/class/org/jboss/netty/bootstrap/ConnectionlessBootstrap.java.htmlConnectionlessBootstrapのandorg.jbossパッケージを使用した例を見つけました。動作するようになったとき、実装を自分のものと比較し、両端にエンコーダーとデコーダーがあることに気付きました。ここで、リスナーにデコーダーを追加するというアイデアを得て、プロジェクトを機能させることができました。CharsetUtil.ISO_8859_1

また、一度に 1 回しか送信できないことにも気付きました。プロパティdisconnectOnNoReplyを false に設定すると、リスナーは切断せずに複数回受信できます。

これが将来誰かに役立つことを願っています。:)

[編集] 実際にさらにテストした結果、「disconnectOnNoReply」は必要ないかもしれません。私はそれなしで試してみましたが、うまくいきます。

于 2013-03-04T16:32:03.323 に答える