Как работают обработчики верхнего и нижнего уровня в Netty ...?

Question

Я новичок в Netty и не очень понимаю поток обработчиков в Netty. То, что я хочу знать, - это разница между обработчиками Upstream и Downstream. Почему мы не можем перехватывать сообщение в обработчиках downstream, как это происходит в восходящем потоке? Имеются ли в нисходящем и восходящем потоках такие же, как в нормальных условиях?

Answer 1

Разница в том, что одна ручка включает в себя (вверх по течению) и другую исходящую (вниз по течению). Я думаю, что поток событий/сообщений становится более понятным после просмотра javadoc ChannelPipeline.

Я также должен отметить, что события восходящего потока будут инициироваться только IO-Thread, поэтому нет необходимости синхронизировать доступ к полю там, если вы используете новый ChannelUpstreamHandler на ChannelPipeline. События нисходящего потока могут быть инициированы любым потоком, поэтому доступ к полям необходимо синхронизировать.

Answer 2

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

Думайте, что каждый обработчик как «один слой», весь конвейер как «один сетевой стек», физическая ссылка как «источник ввода-вывода» и «пользовательская логика приложения» обработчик. Используя тот же трубопровод (стек), мы должны сделать две функциональные

1. Передача данных (отправить данные вниз, когда «логики приложения обработчика» хочет сделать что-то через «источник IO»)
2. получающего данные (передачи данных до, когда «IO источник» имеет какое-то событие, которое может быть интерес «прикладной логики обработчика»)

Так по существу же трубопровод должен сделать две разные вещи (получать сообщения и отправить сообщения назад). Рассмотрим конкретный пример (сервер с аутентификацией и шифрованием), с 3-обработчики решений трубопровода:

Давайте посмотрим на ответственность каждого в-плане приема сообщений

1. обработчик Шифрование - > необходимо получить UpstreamEvent из «Источник IO» и DownstreamEvent из «Обработчик приложений» или «Обработчик ошибок» в приведенных выше потоках.
2. Auth handler -> необходимо получить UpstreamEvent только с 'Encryption handler'.
3. Прикладной обработчик -> необходимо получить UpstreamEvent только от Auth Handler.

Таким образом, по логике, каждый обработчик должен осуществить следующие действия:

1. обработчика шифрования ->ChannelUpstreamHandler и ChannelDownstreamHandler
2. Auth обработчика ->ChannelUpstreamHandler
3. обработчика приложений ->ChannelUpstreamHandler

Итак, если у вас есть ChannelPipeline, с 3-х обработчиком ы упоминалось выше,

• Для входящего сообщения: 'IO источник' (0) инициирует UpstreamEvent и Нетти будет пересылать UpstreamEvent к (1), затем (2), а затем, возможно, (3), так как все три реализовали ChannelUpstreamHandler.
• Когда «Обработчик приложений» (3)/'Auth Handler' (2), хочет отправить сообщение статуса клиенту, тогда он начнет с вызова write (что создает DownstreamEvent). Netty отправит DownstreamEvent в (1) (который является только одним, до (3) и реализован ChannelDownstreamHandler).

Так Учитывая трубопровод с обработчиками, когда UpstreamEvent создается («Источник IO»), Нетти будет вызывать все обработчики в трубопроводе в последовательности от 1 до п, выполнивших ChannelUpstreamHandler (п число обработчиков, в приведенном выше примере n = 3). И когда создается DownstreamEvent (по коду пользовательского приложения), Netty будет вызывать все обработчики в конвейере последовательно от n до 1, которые реализовали ChannelDownstreamHandler. Поскольку класс может реализовывать два интерфейса, обработчик может быть как ChannelUpstreamHandler, так и ChannelDownstreamHandler. Обратите внимание, что все UpstreamEvent создаются «IO Source», а все DownstreamEvent создаются логикой пользовательского приложения.

Примеры UpstreamEvent:

1. полученного сообщение
2. канал открыт
3. канал закрыт
4. исключения поднятого 'источника IO'
5. запись завершена 'Источник IO'
6. канала отключено
7. ...

Примеры DownstreamEvent:

1. Написать сообщение в канал
2. Bind к порту
3. подключиться к адресу сервера
4. ...

Надежда это» помогу вам ответить. Почему нам нужны два поведения для обработчиков (вверх и вниз по течению), как Netty решает отправку и получение через Downstream и Upstream. Как мы можем реально использовать конструкции в реальном мире.

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

Давайте посмотрим на ответственность каждого в-плане пересылки сообщений:

1. обработчик приложений -> необходимо пересылать сообщения на предыдущие слои (должны вызывать ctx.sendDownstream(e) неявно или явно)
2. Auth обработчик -> нужно пересылать сообщения на предыдущие слои (для отказа авт.) и на следующие уровни (для успеха auth). (Следует назвать ctx.sendDownstream(e) и ctx.sendUpstream(e) неявно или явно)
3. Шифрование обработчика -> нужно переслать сообщение для предыдущих слоев и последующих слоев (должны вызывать ctx.sendDownstream(e) и ctx.sendUpstream(e) неявно или явно)