Как работает модель потоков Netty в случае многих клиентских подключений?

Я намерен использовать Netty в предстоящем проекте. Этот проект будет действовать как клиент и сервер. В частности, он будет устанавливать и поддерживать множество соединений с различными серверами и одновременно обслуживать своих клиентов.

Теперь документация для NioServerSocketChannelFactory довольно точно определяет модель потоков для серверной части вещей - для каждого связанного порта прослушивания потребуется выделенный поток босса на протяжении всего процесса, в то время как подключенные клиенты будут обрабатываться неблокирующимся образом в рабочих потоках. В частности, один рабочий поток сможет обрабатывать несколько подключенных клиентов.

Однако документация для NioClientSocketChannelFactory менее конкретна. Это также, по-видимому, использует как босс, так и рабочие потоки. Однако в документации указано:

Один NioClientSocketChannelFactory имеет один поток босса. Он делает попытку подключения по запросу. После успешной попытки подключения поток босса передает подключенный Канал одному из рабочих потоков, который управляет NioClientSocketChannelFactory.

Рабочие потоки, похоже, функционируют так же, как и для сервера.

Мой вопрос в том, означает ли это, что для каждого подключения из моей программы на внешний сервер будет один выделенный поток босса? Как будет эта шкала, если я установлю сотни или тысячи таких соединений?

Как примечание. Существуют ли какие-либо неблагоприятные побочные эффекты для повторного использования одного Исполнителя (пула кэшированных потоков) в качестве обозревателя босса и исполнителя-исполнителя для ChannelFactory? Как насчет повторного использования между различными экземплярами клиента и/или сервера ChannelFactory? Это несколько обсуждается здесь, но я не нахожу эти ответы достаточно конкретными. Может ли кто-нибудь уточнить это?

Ответ 1

Это не реальный ответ на ваш вопрос о том, как работает модель потока клиентов Netty. Но вы можете использовать один и тот же NioClientSocketChannelFactory для создания одиночного ClientBootstrap с несколькими ChannelPipelineFactory и, в свою очередь, сделать большое количество соединений. Взгляните на приведенный ниже пример.

public static void main(String[] args)
{
    String host = "localhost";
    int port = 8090;
    ChannelFactory factory = new NioClientSocketChannelFactory(Executors
            .newCachedThreadPool(), Executors.newCachedThreadPool());
    MyHandler handler1 = new MyHandler();
    PipelineFactory factory1 = new PipelineFactory(handler1);
    AnotherHandler handler2 = new AnotherHandler();
    PipelineFactory factory2 = new PipelineFactory(handler2);
    ClientBootstrap bootstrap = new ClientBootstrap(factory);
    // At client side option is tcpNoDelay and at server child.tcpNoDelay
    bootstrap.setOption("tcpNoDelay", true);
    bootstrap.setOption("keepAlive", true);
    for (int i = 1; i<=50;i++){
        if(i%2==0){
            bootstrap.setPipelineFactory(factory1);
        }else{
            bootstrap.setPipelineFactory(factory2);
        }

        ChannelFuture future = bootstrap.connect(new InetSocketAddress(host,
                port));

        future.addListener(new ChannelFutureListener()
        {
            @Override
            public void operationComplete(ChannelFuture future) throws Exception
            {
                future.getChannel().write("SUCCESS");
            }
        });
    }
}

Он также показывает, как различные заводы трубопроводов могут быть установлены для разных подключений, поэтому на основе вашего подключения вы можете настроить ваши кодеры/декодеры в конвейере канала.

Ответ 2

Я не уверен, что ваш вопрос был ответом. Здесь мой ответ: есть один поток Boss, который одновременно управляет всеми ожидающими CONNECT в вашем приложении. Он использует nio для обработки всех текущих подключений в одном потоке (Boss), а затем передает каждый успешно подключенный канал к одному из рабочих.

Ответ 3

Ваш вопрос в основном касается производительности. Отдельные потоки очень хорошо масштабируются на клиенте.

О, и nabble закрыт. Вы можете просмотреть архив там.