Непосредственно на скорость передачи данных будут влиять только сеть между сервером и клиентом. Я на 99.5% уверена, что по скорости передачи данных разницы не будет. В NIO буферы быстрее пишутся, но сама скорость обмена от этого не зависит.
Да, Ваша модель похожа на модель обычной реал-тайм игры, сети которой данная статья и посвящена.
Если передач мало (на одного клиента в секунду), то Netty Вам даст отличный результат производительности, т.к. у Вас не будет висеть по два потока на клиента, которые в пустую ждут данные, а будет один (или больше, если клиентов станет больше потом, то можно легко добавить потоки), который будет иногда принимать/отправлять данные.
Если передач много, клиентов мало (и больше не станет точно), то простота написания обычного IO тут может выиграть.
Вообще, в Вашем случае не факт, что Netty даст лучший результат, чем блокирующее IO по два потока на клиента. Когда клиентов мало, такая система хорошо работает. В любом случае, сделать блокирующее IO намного проще NIO, так что советую поэкспериментировать, если не лень.
При создании pipeline определяется, какой обработчик в какую сторону работает — те, что наследуют интерфейс ChannelUpstreamHandler работают в сторону «пользователь -> сервер», те, что ChannelDownstreamHandler— в обратную сторону. В моём случае, ChannelDownstreamHandler только PacketFrameEncoder, который наследуется от OneToOneEncoder, который реализует этот интерфейс.
Второе: очевидно, я опустила некоторые внутренние подробности работы PlayerHandler специфические только для моеё реализации логики — deocder и encoder передаются ему, чтобы можно было управлять режимом передачи пактов.
PlayerWorkerThread не является Thread, просто название так получилось исторически. На самом деле, это просто объект, который хранит информацию об игроке. Обработкой этой информации занимается уже «бизнес-логика».
Можно попросить Вас покинуть мою уютную статью? Я не собираюсь объяснять своё мировоззрение на minetest. Но сревер мы пишем только потому, что нотчевская подделка годна лишь для сингла. Зайдите к нам и поиграйте, у нас другой майнкрафт.
Эффективнее — это точно. Но у меня протокол был разработан задолго до меня. Я хоть и вношу в него изменения сейчас, но времени переписывать клиентскую реализацию пока нет. Когда руки дойдут, переделаю на FrameDecoder. Там много пакетов содержит строки неизвестной заранее длины (причём обычно несколько строк) или массивы байт/шортов и тоже по-несколько. Можно добавить к таким динамическим пакетам в начало общую длину, думаю, так будет эффективнее.
Если передач мало (на одного клиента в секунду), то Netty Вам даст отличный результат производительности, т.к. у Вас не будет висеть по два потока на клиента, которые в пустую ждут данные, а будет один (или больше, если клиентов станет больше потом, то можно легко добавить потоки), который будет иногда принимать/отправлять данные.
Если передач много, клиентов мало (и больше не станет точно), то простота написания обычного IO тут может выиграть.
Вообще, в Вашем случае не факт, что Netty даст лучший результат, чем блокирующее IO по два потока на клиента. Когда клиентов мало, такая система хорошо работает. В любом случае, сделать блокирующее IO намного проще NIO, так что советую поэкспериментировать, если не лень.
При создании pipeline определяется, какой обработчик в какую сторону работает — те, что наследуют интерфейс ChannelUpstreamHandler работают в сторону «пользователь -> сервер», те, что ChannelDownstreamHandler— в обратную сторону. В моём случае, ChannelDownstreamHandler только PacketFrameEncoder, который наследуется от OneToOneEncoder, который реализует этот интерфейс.
Второе: очевидно, я опустила некоторые внутренние подробности работы PlayerHandler специфические только для моеё реализации логики — deocder и encoder передаются ему, чтобы можно было управлять режимом передачи пактов.
PlayerWorkerThread не является Thread, просто название так получилось исторически. На самом деле, это просто объект, который хранит информацию об игроке. Обработкой этой информации занимается уже «бизнес-логика».
Спасибо, не задумывалась об этом так серьёзно :)