Netty Różne potoki na UDP Datagram

Mamy serwer, który jest już zaimplementowany w TCP / IP, ale teraz mamy wymóg, aby protokół obsługiwał także UDP.

Każdy wysłany datagram UDP zawiera wszystko, czego potrzebuję do dekodowania, więc jest to bardzo prosty system odpowiedzi i odpowiedzi z danymi w datagramie oddzielonymi podziałami linii.

Kod bootstrapu podczas uruchamiania serwera pokazano poniżej:

<code>    //SETUP UDP SERVER
    DatagramChannelFactory udpFactory = new NioDatagramChannelFactory(Executors.newCachedThreadPool());

    ConnectionlessBootstrap udpBootstrap = new ConnectionlessBootstrap(udpFactory);

    udpBootstrap.setOption("sendBufferSize", 65536);
    udpBootstrap.setOption("receiveBufferSize", 65536);
    udpBootstrap.setOption("receiveBufferSizePredictorFactory", new AdaptiveReceiveBufferSizePredictorFactory());

    udpBootstrap.setOption("broadcast", "true");
    udpBootstrap.setPipelineFactory(new ServerPipeLineFactoryUDP());
    udpBootstrap.bind(new InetSocketAddress(hostIp, 4000)); 
</code>

Kod potoku to:

<code>class ServerPipeLineFactoryUDP implements ChannelPipelineFactory
{

    private final static ExecutionHandler EXECUTION_HANDLER = new ExecutionHandler(new OrderedMemoryAwareThreadPoolExecutor(ScorpionFMS.THREAD_POOL_COUNT, 0, 0));

    public ServerPipeLineFactoryUDP()
    {

    }

    @Override
    public ChannelPipeline getPipeline() throws Exception
    {

    ChannelPipeline pipeline = pipeline();
    pipeline.addLast("debugup", new DebugUpstreamHandler("UDP"));
    pipeline.addLast("debugdown", new DebugDownstreamHandler("UDP"));

    pipeline.addLast("framer", new DelimiterBasedFrameDecoder(256, Delimiters.lineDelimiter()));

    pipeline.addLast("decoder", new UDPRequestDecoder(true));
    pipeline.addLast("encoder", new StringEncoder());
    pipeline.addLast("executor", EXECUTION_HANDLER);
    pipeline.addLast("handler", new UDPRequestHandler(

    return pipeline;
    }
}
</code>

Problem polega na tym, że każdy datagram używa tej samej instancji tego potoku (miałem nadzieję, że każdy datagram użyje nowej instancji potoku), więc cały stan, jaki przechowuję podczas przetwarzania, zapisuje zawartość datagramu i używa następnego datagramu to również, (podczas gdy dla TCP każde połączenie miałoby swój własny kanał, a zatem własne wystąpienie potoku i jego własny stan)

Wiem, że jest to oczekiwane zachowanie po przeczytaniu dokumentacji, ale czy mimo to zmusić netty do odtworzenia potoku dla każdego datagramu? A może chodzę o tym w zupełnie zły sposób?

Mówiąc krótko, chcę, aby każdy datagram miał nową instancję potoku (tak samo jak tcp)

questionAnswers(2)

yourAnswerToTheQuestion