Пьеса «Разработка многопользовательской сетевой игры.» Часть 3: Клиент-серверное взаимодействие

На самом деле есть свои «за», но очень много «против». Но это уже тема отдельного разговора — что лучше использовать: готовые решения или свои собственные. Недостаток подобных библиотек в том, что они пытаются быть универсальными и покрыть как можно большее число потенциальных задач. Тогда как реальная задача требует всего одного-единственного решения, зато хорошо контролируемого и легко адаптируемого.

Навскидку я не уверен, что Netty мне обеспечит:
— контроль длины и валидности входящих сообщений
— лимитирование коннекшнов с одного IP (против DoS)
— blacklist IP и сеток
— heartbeat, и автоматическое определение времени ping-а
— flooding-контроль
— remote-контроль валидности клиентского кода
— отсоединение неактивных клиентов
— если внезапно понадобится еще что — допишу

Другой недостаток библиотек — это синдром «черного ящика», когда не ясно как чужой код ведет себя при определенных условиях. Требует экспериментальных проверок, а иногда уже на production выползают очень интересные «фичи». Ну и естественно зависимость от производителя…

И все-таки причиной создания «велосипеда» было то, что он был написан, когда появился NIO (1.4.1). Netty и подобных фреймворков и в помине не было. Раньше были танцы с бубном, когда надо было обойти blocking io.

P.S. Про netty кстати не знал, спасибо. Хотя уверен, это не единственное решение (напр. Apache Camel).