Обновить
4
0
Solver@solver

Back-end developer

Отправить сообщение
Да самому интересно… всегда прикалывало как такие выскочки накидают понтов и в кусты ))
Полноценно не сможет. И думаю еще долго не сможет.
Ну покажите же нам это чудо. Покажите нам однотредовое приложение на чудо языке, которое 150к сообщений в секунду гоняет при этом еще выполняя полезную работу.
Или опять одни понты?
В первую очередь объясняют адекватным. Вы же только обсираете всех… чего же вы хотите в ответ услышать?
Да вы что… вот оно в чем дело, ведь в статье-то я написал, что это архитектура самых крутейших серверов на свете… а оно вона как…
У вас случайно нет мании величия? Даже если в ваших словах есть хоть капля истины (в чем я сильно сомневаюсь т.к. кроме понтов ничего еще не видел). В сатье написано, что это всего лишь один из вариантов как сделать сервер.
Который не является самым крутым на свете.

А вы вместо того чтобы пальцы гнуть, лучше каписали бы как делают крутые перцы… а то походу вы кроме распальцовок ничего не умете…
Да именно так и есть. Вы не понимаете что такое ThreadPool, не удосужились заглянуть в доки и посмотреть. Поэтому объяснять очевидные истины никому неохота. Тем более человеку который ничего не хочет делать, а только тыкает всех носом, да еще неправильно тыкает. Понимаете? Вы пишете очевидную ерунду. Поэтому вам и не разжевывают. Вели бы себя как нормальный человек, возможно кто-то потратил бы минутку чтобы разжевать вам.
Хватит уже показывать какой вы умный, не приведя ни одного реального примера.

Утрите мне нос, покажите как делают реальные джедаи.
Напишите свое видение, откройте нам глаза. Мы будем благодарны. Только не надо тут холиварить и тролить…
Э. Вы это серьезно? Т.е. сможете показать однотредовое решение которое дает на одном нетбуке 20к сообщений в сек, а на нормальном сервере более 150к сообщений?
Если вы не приведете пруф, то будем считать, что вы врун и пернули в лужу…
Ну, блокировки всех одним не будет, т.к. потоков обрабатывающих sessionQueue.add много. Посмотрю как оно себя поведет при онлайне в 20-30к (если такое получится) ), а пока на паре тысяч клиентов это не заметно. К тому же в сервере есть понятие флуд, для блокировки бессмысленных сообщений и клиентов. Что касается saturated outbound, то я не планировал разложить по полочкам абсолютно все ньюансы работы сервера. На это легко можно пару десятков статей угрохать…
Тут недавно была статья про сервер на Netty. Там была описана обработка пакетов. В каментах меня попросили описать как это я делаю. Я написал.
Хотя в своем цикле статей про мультиплеер игрушку я и планировал затронуть многие аспекты разработки сервера, но не у уверен, что там будет абсолютно все.

P.S. У вас должен быть приличный опыт разработки серверов. Может поделитесь своими соображениями по этому поводу? )
Подробностей не будет, т.к. я не пишу на нем ничего. Я попробовал сделать на нем тестовый проект. Посмотрел как там все делается и мне не понравилось. Плюс последний раз он обновлялся в 2010 году, так что считаю это мертвая разработка. Сановцы просто не успели вывести RedDwarf на нормальный уровень.
Это как сравнивать двигатель внутреннего сгорания и готовый автомобиль ))
Netty это сетевая библиотека. А RedDwarf Server это готовый игровой сервер.

Да. Я его смотрел. Мне не очень понравилось. После того как его бросил оракл, после покупки сана, развитие его практически остановилось а самой главной фишки, прозрачного масштабирования, в нем так и не сделали…
Можете пояснить фразу «TCP поток может приходить быстрее, чем выгребается очередь»?
И заодно про изобретенные велосипеды их нормальную реализацию в java. Как говорится век живи — век учись.
Если честно, даже не знаю что сказать… почитайте теорию по всем пунктам.
1. Вы серьезно? Если не создавать объект то что делать? Напишите, мы все поучимся…
2. Сервер работает сутками, потребляемая память меняется, как ей и положено.
3. Вы вообще знаете что такое ThreadPool ?? Вы походу вообще не понимаете о чем говорите.
Про 4 потока в нетти вам уже несколько раз сказали, что вы ерунду говорите.
Да. 1 пакет может попасть в один поток, а второй пакет во второй поток. Обычно именно так и происходит.

Нет. В сервере нет обработчика «Как повезет». Они будут обработаны последовательно, по мере получения.
Поддержка protobuf в Netty есть. Но она не для всех случаев подходит. Если точнее, то он сработает только если если и клиент и сервер сделаны на Netty. А вот если у вас клиент например на флеше, то все, суши весла )
1,2. Можете руками его убивать если вам так жалко напрягать GC )
3. Походу вы просто не понимаете как оно все работает. Никто не создает поток на каждого из 20к клиентов. Почитайте теорию про многопоточность, многое прояснится.
И откуда вы взяли 4 потока нетти? Я в конфиге нетти могу 10 задать.
Если честно не понимаю, почему я должен понимать, что вы не извлекете что-то новое )
И опять же не понимаю как вопрос «А почему не использовать protocol buffers?» относится к обсуждению статьи про сервер, в которой про реализацию протокола нет ни слова…
Странные вопросы… Нетти их вообще не обрабатывает, она только их принимает. Примет нетти их отлично, в несколько потоков… на десктопе у меня вообще 40-50к принимает и ничего все Ок. В чем конкретно проблема?
Хм… Статью не читал, но спрашиваю? )

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность