Netty

[n3k0nation]

оно и видно, для того, чтобы заюзать 1 класс, они тянут всю библиотеку, заместь того чтоб использовать стандартные классы и потом получается проект с 100500-ю библиотеками зависящий от них

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

Чем Вам дефолтный NIO то не угодил?

Соотношение по времени разработки, не так ли? Если бы у людей была приблизительно бесконечность времени на каждый продукт, то все бы писали свои фреймворки.

Оффтоп

Увидев название темы я сразу вспомнил ASevenfold :redlol:

Я уже тут =D

офф

А при чём тут он?) Обложил бы за неумение пользоваться стандартным нио?

Не надо выставлять меня таким злым.

Интересно, кто-нибудь делал бенчмарки netty vs java nio2 ? Что-то мне подсказывает, что перевес будет не в сторону сана оракла.

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

[ProDev]

Соотношение по времени разработки, не так ли? Если бы у людей была приблизительно бесконечность времени на каждый продукт, то все бы писали свои фреймворки.

Именно. Нужно соизмерять временные затраты и необходимость низкоуровневой реализации. Плюс ко второму нужно добавить довольно высокий скилл разработки, ибо зачастую получается менее оптимальный код. И сразу вспоминается холивар на тему Hibernate vs. plain SQL

[Ozzy]

Оффтоп

Я уже тут =D

Я и не сомневался что ты тут появишься :redlol:

[shocked]

Возник вопрос по данной библиотеке. Если от клиента приходит "склеенный" пакет (несколько пакетов в одном фрейме), то нужно самому их разделять или netty сам это делает (что то читал про ReplayingDecoder, но не до конца понял)

[acmi]

Для разделения пакетов можно использовать неттиевские классы:
addDecoder(new LengthFieldBasedFrameDecoder(Short.MAX_VALUE,0,2,-2,2));
addEncoder(new LengthFieldPrepender(2, true));

[shocked]

Спасибо. LengthFieldBasedFrameDecoder похоже то что нужно. А еще вопрос по "best practice" - в самом decoder`е лучше уже собирать готовый пакет и дальше обрабатывать в messageRecieve() или не обязательно ?

[acmi]

Моя схема обработки: LengthFieldBasedFrameDecoder->?Decoder(extends FrameDecoder)->PacketHandler(extends SimpleChannelHandler)
где ?Decoder:
логин сервер - BlowfishDecoder
гейм сервер - XORDecoder
Decoder`ы обрабатывают поток байтов, сами пакеты собираются в PacketHandler`е.

[shocked]

В l2 поле длинны не криптуется ? Думаю тоже также сделать , только местами изменить LengthDecoder и "Crypt"Decoder

[acmi]

Эмм пакеты же сначала разделяются по длине, а потом уже декодируются.

[shocked]

В тере все целиком криптуется например.
Приходит два склееных первых пакета закриптованых Размер 123

packet

6B 11 5A 8B 25 C9 63 50 B3 98 52 5D A9 F0 6B 5E F6 C7 2D 60 F9 87 6B 32 CA 3C 14 FF 76 2F 55 B4 E5 FA 50 79 82 5C EB 7C 33 9D C9 17 17 DD 78 40 C6 80 5B 24 37 8B 42 99 3D 78 59 8F CD F1 66 BF 3A D4 7B 54 6F 11 03 8B F7 52 88 C6 A5 BF EC B3 32 C8 5F C0 0A 9F 27 0A 61 2E 19 59 D5 00 3E DE E2 EC BC 51 24 AA A4 8D 4A EC C8 53 01 68 09 45 AA 7A E3 C5 46 7F 06 A8 50 6B DB

И дальше расщепляются

2

20 00 bc 4d 02 00 08 00 08 00 14 00 00 00 00 00 47 61 03 00 14 00 00 00 01 00 00 00 e5 61 03 00

5b 00 75 ea 13 00 29 00 32 00 00 00 00 00 00 02 00 00 00 50 00 47 00 52 00 48 00 46 00 54 00 48 00 57 00 54 00 46 00 00 00 43 54 75 58 50 6d 43 79 73 50 78 52 6d 74 41 57 6d 62 78 64 45 24 74 4e 4a 34 4e 37 4c 76 58 47 54 6b 35 65 68 33 36 5f 59 62 59 4d 44 72 2d 68 4b 5f

Длина - первые два байта