Реализация пользовательского Netty ServerChannel

Question

У меня есть две системы, которые я бы хотел интегрировать: один, который использует полностью собственный сетевой стек, и один (в частности, Flazr), который использует Netty. Я хочу проксировать RTMP Flazr Netty через наш собственный HTTP-стек, чтобы получить систему, которая говорит RTMPT.

Для этого мне нужен объект Netty, который действует как сокет, но сам позволяет мне выполнять все «низкоуровневые» вещи - в основном просто обертывать данные в HTTP и передавать его в наш пользовательский сетевой стек. Другими словами, я не хочу, чтобы Netty управляла любыми сокетами для меня - я хочу вставить свои собственные вещи между сокетом и Netty.

Я подозреваю, что правильный путь для этого состоит в том, чтобы расширить AbstractServerChannel и создать класс * Factory, но я не уверен, как остальные Netty ожидают, что данные будут проходить через ServerChannel.

Мой заказ ServerChannel должны быть в состоянии:

• Уведомить Нетти, когда новый клиент подключается через нашу существующую систему HTTP

• Push-данные до Нетти, когда он прибывает

• Опрос о новых сообщениях от Netty по просьбе клиента

• Очистка состояния Netty, когда времена HTTP сессии из (или поток RTMP закрыт чисто)

Любые указатели о том, как ServerChannel, ServerChannelFactory должны быть реализованы? Я обнаружил, что javadocs не хватает в этой области.

Некоторые конкретные вопросы:

• Как должен мой реагировать реализации на "InterestOps" -типа материал?

• Является ли ServerChannel.write тем, что вызывается для сообщений, которые полностью удаляются по стеку? Что случилось с двумя разными перегрузками?

• Как мне реализовать ServerChannel. (Dis) connect?

• Должен ли я все еще делать все это через ServerBootstrap, или это слишком высокий уровень для этого материала?

Спасибо!

Прежде, чем кто-нибудь спросит: ДА, я хотел бы заменить наш пользовательский сетевой стек на основе Netty, но это большая инженерная задача, которую мне было бы трудно оправдать. Шаги малыша.

Answer 1

Похоже, вы пытаетесь внедрить новый асинхронный транспорт, поэтому стоит взглянуть на NIO TCP transport (кроме классов Datagram).

Я не уверен, насколько актуальна она есть, но это поможет понять, как написать новую транспортную услугу для Нетти (так как вы спросили о сервере, клиентские каналы, заводы, и все)

Это будет быть проще Если вы можете понять модель событий Netty и как проходит конвейер. Это мое понимание того, как это работает.

• Upstream события (события из сети) начинается с Channel/ServerChannel, Boss/NioWorker и отправить через трубопровод, пока он не достигнет последнего обработчика.

• События в нисходящем потоке начинаются с последнего обработчика нисходящего потока и отправляются по трубопроводу и опускаются по адресу ChannelSink, приемник канала обрабатывает события и предпринимает действия или помещает сообщения в очереди каналов.

Более подробно (я предполагаю, что кто-то ищет классы транспорта Nio TCP, чтобы написать свой собственный транспорт для Netty).

NioWorker - О событиях селектора для каналов (все NioClientSocketChannel, NioAcceptedSocketChannel), запускает NiO петли - Данные, полученные от сети: огнь полученного сообщения - опроса очереди на запись и делают без блокировки запись - задача опроса очередь для интересующих событий op и приостановить/возобновить канал ?.

Boss

• Запускается цикл обработки событий сервера NIO.
• Accept сокет клиента, создает NioAcceptedSocketChannel и зарегистрировать селекторы для NioWorker

NioClientSocketPipelineSink

• Имеет рабочий пул потоков исполнителя.
• Отправить NioWorker runnables для рабочего пула потоков в конструкторе.
• Здесь происходит остановка событий в канале канала и помещается в очередь очереди на запись/очередь задач, перехватывает некоторые события состояния восходящего потока и управляет состоянием канала.

NioServerSocketPipelineSink

• Имеет боссу пул потоков.
• Отправить Nio рабочий runnables для исполнителя при создании.
• Представьте босса, запускаемого с ServerSocketChannel, исполнителю на событие bind.
• Здесь происходят потоки событий сервера, перехватывают некоторые события состояния восходящего потока и управляют состоянием ServerSocketChannel.

Как должна моя реализация реагировать на вещи типа "InterestOps"?

Это зависит от характера канала (блокировки/блокировки) и ограничений.

Является ли ServerChannel.write тем, что вызывается для сообщений, которые попадают в стек? Что случилось с двумя разными перегрузками?

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

ChannelFuture write(Object message); 

ChannelFuture write(Object message, SocketAddress remoteAddress); 

Этих методов Канала существует для установления соединения транспортировки. Для TCP оба фактически делают то же самое.

Как мне реализовать ServerChannel. (Dis) connect?

канал сервера не должен поддерживать эти вызовы методов, но вы должны реализовать, bind и unbind здесь.

Должен ли я все еще делать все это через ServerBootstrap, или это слишком высокий уровень для этого материала?

Серверные/клиентские бутстрапы - это только вспомогательные классы для управления ресурсами конвейера и обеспечения фасадного соединения, соединения &. Вы должны выполнить большую часть логики в

Client, Impls канала сервера
Client, Server Pipeline тонет
классов Boss, рабочих,

Тогда вы должны реализовать клиенту & заводов канала сервера с использованием вышеуказанных классов, если все это будет сделано, вы можете просто настроить ваш сервер &, используя классы Bootstrap.