Включим паранойю: возможно создание биткоина — спланированная этими самыми ребятами из WallStreet провокация. И если бы они действительно беспокоились за свое благосостояние, то в ход бы пошли другие силы и средства. А так биткоин похоже никто не принимает всерьез.
JavaFX надо было делать 10 лет назад. Все, паровоз уехал. Сейчас идет повсеместный отказ от плагинной архитектуры и шаг в сторону мобильных. Куда они будут его ставить — совершенно непонятно. Что плохо:
— Где полноценный мигратор с 1.3 на 2.0? На разрекламированном в свое времяJavaFX script сделаны реальные проекты. И что теперь с ними делать?
— Помимо JRE еще просят установить еще один плагин. Количество пользователей (клиентов => бабла), имеющих терпение что-то там устанавливать, чтобы посмотреть демку уменьшится раз в 5.
— Обещали апаратное ускорение в prism. Незаметно.
— Версии под «все платформы» (а это десктопный Win/Mac/Lin) появятся только к концу 2012 года (если не произойдет ничего странного, например Apple выпилит Java)
И вообще, JavaFX может быть адекватно заменен Html5 + SVG.
Насколько я понимаю, он предоставляет прокси-библиотеку для доступа к сервисам платформы, а также генерирует обертку и пакетирует апликацию. Однако сам html5-код не конвертируется. То есть на платформе работает тот же самый html5+css3+js.
Важно то, как машина будет себя вести в аварийной ситуации, или при неисправности/потери управления и любой другой нештатной ситуации (бабка на дороге).
Пример некорректен, поскольку любой требуемый функционал описывается конечным автоматом и имеет конечное множество возможных состояний. Программа, которая имплементирует функционал, также имеет конечное множество состояний, причем такое, чтобы включить в себя все множество требуемого функционала.
Проблема как раз в том, что как правило программа не точно соответствует требуемому функционалу, а намного больше, и включает в себя состояния, которые не соответствуют требуемым («дополнение»). При нормальном использовании программа не входит в эти состояния. Однако задача хакера — разработать протокол работы, который вводит систему в такие состояния.
Тем не менее множество «дополнений» также конечно. Соответственно и уязвимостей конечное количество. Откуда они берутся? Использование сторонних библиотек, фреймворков, «нестабильных» методов программирования, неявных допущений. Но все это уже давно изучено и выработаны методы анализа всей системы на уязвимость. Да, изначально мы не знаем точное количество уязвимостей, которые есть в системе. Однако каждая обнаруженная потенциальная уязвимость уменьшает вероятность системы быть взломаной.
С другой стороны, у нас есть статистика взломов, благодаря которой мы можем реально оценивать вероятность уязвимостей в системах, соответствующих тому или иному критерию. Скажем, если ни одна SFOD-12 за определенный промежуток времени не была взломана, мы можем дать вероятностную оценку данному критерию.
Гы. Интересно. Практически 10 лет занимаюсь разработкой игровых серверов на Java, а об этом проекте не слышал. Насколько я понял, вся платформа крутится вокруг персистентной Software Transactional Memory. Причем реализует она ее не в лучшей форме — через искусственные объекты и ManagedReference. Другие фреймворки (напр. Multiverse) прозрачно используют для этого bytecode enhancing. Все остальное — плюшки типа коннекшнов и каналов, которые без реализуются отденьго. Реальная инфраструктура игрового сервера несколько сложнее, чем предоставляет эта платформа. По моему опыту наиболее подходящей для игрового сервера является модель акторов, а использование STM здесь мне кажется лишним.
Интересная схема. Свои соображения всегда приветствуются, однако при этом неплохо бы заглянуть в чужие виртуальные конструкции и хотя бы примерно знать матчасть. Основное неудовлетворение происходит от несоответствия желаемого действительному. Ощущение собственной некомпетентность компенсируется проекцией вины на окружающий мир.
Отрицая чужие виртуальные конструкции и живя в своих, Вы уподобляетесь Незнайке. Задача человека — перенять чужой опыт, изменить его (внести свою долю/понимание, адаптировать, доработать, изобрести лучшую концепцию), и передать другим. Изобретать же каждому свой велосипед по меньшей мере неэффективно.
Точно такой же вопрос возник с самого начала статьи. Помню времена, когда на еще на Паскале я делал разные динамические структуры в качестве задания… Кольцевой LinkedList я использовал для хранения виджетов в контейнере, чтобы удобней было Tab-ом фокус переключать.
Вообще LinkedList не позволяет random-access и может обрабатываться только последовательно. Поэтому область его применения сильно ограничена. ArrayList реально работает и быстрее и эффективнее.
… (обрезали)… (M «много меньше» N). Планировщик позволяет эффективно распределить очередь задач для каждого треда.
Переключение контекстов и большое количество тредов — это далеко не основная причина выбора асинхронной модели. Более того, в асинхронной архитектуре будет больше переключений контекста, нежели в синхронной. Основная задача — это отказ от разделяемых состояний и соответственно исключение транзакций и блокировок общих ресурсов из работы системы. Именно там теряется производительность, особенно если какой-то ресурс не очень быстрый. Вместо одной долгой транзакции, связывающей и блокирующей одновременно множество компонентов на все время выполнения, каждый компонент работает независимо, а связь между ними осуществляется асинхронно. Управляет всем этим асинхронный процесс или конечный автомат (что по-сути одно и то же).
Кроме того, асинхронную архитектуру очень просто масштабировать горизонтально, просто раскидав компоненты по разным тачкам и обеспечив между ними обмен сообщениями.
Как плата за масштабируемость — это потеря целостности состояния всей системы в любой момент времени. Поэтому задача должна быть сначала адаптирована, чтобы целостность не была критична. В самом деле, не критично, если на френдленте пост появится на пару секунд позже, нежели в блоге афтора.
Любой веб сервер функционирует не совсем так как Вы описали. У него есть уже пул предсозданных тредов (рабочих лошадок). Любой запрос перенаправляется для выполнения свободному треду. По окончании тред возвращается обратно в пул.
Но даже при 10000 тредах большинство из них находится в состоянии ожидания. Проблема переключения контекстов отчасти решается при помощи Green Threads, когда N виртуальных тредов мэпятся в M нативных (M
Я думаю, дело здесь в том, что нативные маковские виджеты выглядят гораздо более привлекательно, чем виндовые. ;)
Вообще все касается специфики апликации. Если мы разрабатываем рабочую среду, то да, нативный лук будет привычнее. А если же это, скажем, игра?
Кроме того, каждый день мы используем огровное количество сайтов, которые имеют совершенно разный дизайн и лук. И нас это не смущает…
Спасибо за обзор. Думаю использовать Spring DM в следующем проекте, однако в специфику пока не вникал. Посему есть несколько неясностей. Буду признателен, если проясните. Пусть модуль P предоставляет некий сервис с интерфейсом I и несколько связанных с ним структур данных, а модуль C его собирается использовать.
1. Как передаются параметры при вызове от модуля к модулю: по значению (сериализация-десериализация), или по ссылке?
2. Как происходит резольвинг классов между модулями? Насколько я понимаю, каждый модуль имеет свой ClassLoader. И насколько я понимаю, delegation между ними не используется. Иначе когда модуль P недоступен, С не смог бы сделать резольвинг интерфейса I. То есть модуль C использует непосредственно классы из P или имеет собственную копию exported-пакетов?
3. А что будет если мы внезапно запустили новую версию сервиса P, которая поменяла интерфейс I и несколько экспортнутых классов? Если передача параметров идет по значению, то проблем не должно быть если классы остались serializable-совместимыми. Если же по ссылке, то возникнет ClassCastException, т.к. модуль C уже отрезольвил старую версию классов.
4. Я слышал, что можно одновременно иметь несколько версий одного и того же сервиса. И что consumer будет использовать именно последнюю версию сервиса. Можно ли как-нибудь динамически контролировать какую версию сервиса использовать?
5. Чтобы сделать unit-тесты для сервисов без испльзования OSGi, как я понимаю, очень несложно. Для этого нужно прописать соответствующие сервисы в тестовом spring context. А как делать автоматические integration-тесты в OSGi-контейнере? Есть какая-нибудь тулза?
На самом деле есть свои «за», но очень много «против». Но это уже тема отдельного разговора — что лучше использовать: готовые решения или свои собственные. Недостаток подобных библиотек в том, что они пытаются быть универсальными и покрыть как можно большее число потенциальных задач. Тогда как реальная задача требует всего одного-единственного решения, зато хорошо контролируемого и легко адаптируемого.
Навскидку я не уверен, что Netty мне обеспечит:
— контроль длины и валидности входящих сообщений
— лимитирование коннекшнов с одного IP (против DoS)
— blacklist IP и сеток
— heartbeat, и автоматическое определение времени ping-а
— flooding-контроль
— remote-контроль валидности клиентского кода
— отсоединение неактивных клиентов
— если внезапно понадобится еще что — допишу
Другой недостаток библиотек — это синдром «черного ящика», когда не ясно как чужой код ведет себя при определенных условиях. Требует экспериментальных проверок, а иногда уже на production выползают очень интересные «фичи». Ну и естественно зависимость от производителя…
И все-таки причиной создания «велосипеда» было то, что он был написан, когда появился NIO (1.4.1). Netty и подобных фреймворков и в помине не было. Раньше были танцы с бубном, когда надо было обойти blocking io.
P.S. Про netty кстати не знал, спасибо. Хотя уверен, это не единственное решение (напр. Apache Camel).
В таком случае элемент интерфейса должен выглядеть как «Начать ска...». Выползание — вообще плохой стиль. Мы поддерживаем продукт на 5 языках. Основное требование к переводу — чтобы длина сообщения не превышала дефолтную, в качестве которой выступает сообщение на испанском. В данном случае «Сканировать» — наиболее подходящее.
С другой стороны, ситуация выправляется при помощи flexible layouts, когда элементы интерфейса могут тянуться пропорционально тексту. Кроме того, умные лейауты позволяют унифицировать размер группы виджетов по максимально необходимому.
www.buho21.com
Сообщений конечно же не 100, это я ошибся. 700 партий где-то по секунде-полторы на ход, то есть 500-700 сообщений в секунду. Обратный треффик больше: сообщение приходится реплицировать нескольким клиентам. В случае общего чата каждое сообщение или изменение графа отправляется всем пользователям.
Сервер разделен на 4 зала. Коннектор — отдельный процесс, который обслуживает все соединения с клиентами во всех игровых залах. Своего рода диспетчер пакетов и соединений. Интерфейс с серверами ввиде очереди сообщений через обычный Socket с блокирующим I/O. Сейчас, при 2000 пользователях он показывается в top с 7% CPU. Основное время тратится на шифровку/дешифровку пакетов.
У меня игровой сервер. Держит каждый день 2500 юзеров, в целом 100 сообщений в секунду. Пиковая нагрузка была 5000+, сервер выдерживал без проблем. Я делаю все I/O в одном треде. Только после того как буфер с сообщением будет полностью прочитан, я передаю его пулу обработчиков. Как показывает практика, сама работа с I/O некритична и не жрет процессорное время, т.к. занимается исключительно тупой переброской данных между JVM и низлежащей ОС. Пытался одно время распараллелить I/O, вешая каналы на разные треды и селекторы, но под линуксом обнаружился очень странный эффект: он не давал открыть больше одного селектора на процесс, хотя под виндами все работало.
4. Не совсем уверен, что корректно делать Select в одном треде, а обрабатывать SelectionKey в другом (ClientHandler). Мне кажется keys, они валидны только до следующей операции select, посему обрабатываться должны в том же треде.
5. Ваш сервер не обрабатывает отсоединение клиентов. Именно тут начнутся танцы с бубном. Наперед скажу, что не гарантируется, что для каждого отвалившегося клиента селектор вернет key.isValid()=false. Поэтому дисконнект нужно делать по IOException.
Кроме того, есть клиенты, которые при потере связи не пошлют TCP CLOSE-WAIT, и на сервере они останутся висеть бесконечно долго. Timeout возникнет только, если в буфере есть что послать клиенту. Поэтому чтобы такого не произошло, нужно пинговать клиента.
— Где полноценный мигратор с 1.3 на 2.0? На разрекламированном в свое времяJavaFX script сделаны реальные проекты. И что теперь с ними делать?
— Помимо JRE еще просят установить еще один плагин. Количество пользователей (клиентов => бабла), имеющих терпение что-то там устанавливать, чтобы посмотреть демку уменьшится раз в 5.
— Обещали апаратное ускорение в prism. Незаметно.
— Версии под «все платформы» (а это десктопный Win/Mac/Lin) появятся только к концу 2012 года (если не произойдет ничего странного, например Apple выпилит Java)
И вообще, JavaFX может быть адекватно заменен Html5 + SVG.
Проблема как раз в том, что как правило программа не точно соответствует требуемому функционалу, а намного больше, и включает в себя состояния, которые не соответствуют требуемым («дополнение»). При нормальном использовании программа не входит в эти состояния. Однако задача хакера — разработать протокол работы, который вводит систему в такие состояния.
Тем не менее множество «дополнений» также конечно. Соответственно и уязвимостей конечное количество. Откуда они берутся? Использование сторонних библиотек, фреймворков, «нестабильных» методов программирования, неявных допущений. Но все это уже давно изучено и выработаны методы анализа всей системы на уязвимость. Да, изначально мы не знаем точное количество уязвимостей, которые есть в системе. Однако каждая обнаруженная потенциальная уязвимость уменьшает вероятность системы быть взломаной.
С другой стороны, у нас есть статистика взломов, благодаря которой мы можем реально оценивать вероятность уязвимостей в системах, соответствующих тому или иному критерию. Скажем, если ни одна SFOD-12 за определенный промежуток времени не была взломана, мы можем дать вероятностную оценку данному критерию.
Отрицая чужие виртуальные конструкции и живя в своих, Вы уподобляетесь Незнайке. Задача человека — перенять чужой опыт, изменить его (внести свою долю/понимание, адаптировать, доработать, изобрести лучшую концепцию), и передать другим. Изобретать же каждому свой велосипед по меньшей мере неэффективно.
Вообще LinkedList не позволяет random-access и может обрабатываться только последовательно. Поэтому область его применения сильно ограничена. ArrayList реально работает и быстрее и эффективнее.
Переключение контекстов и большое количество тредов — это далеко не основная причина выбора асинхронной модели. Более того, в асинхронной архитектуре будет больше переключений контекста, нежели в синхронной. Основная задача — это отказ от разделяемых состояний и соответственно исключение транзакций и блокировок общих ресурсов из работы системы. Именно там теряется производительность, особенно если какой-то ресурс не очень быстрый. Вместо одной долгой транзакции, связывающей и блокирующей одновременно множество компонентов на все время выполнения, каждый компонент работает независимо, а связь между ними осуществляется асинхронно. Управляет всем этим асинхронный процесс или конечный автомат (что по-сути одно и то же).
Кроме того, асинхронную архитектуру очень просто масштабировать горизонтально, просто раскидав компоненты по разным тачкам и обеспечив между ними обмен сообщениями.
Как плата за масштабируемость — это потеря целостности состояния всей системы в любой момент времени. Поэтому задача должна быть сначала адаптирована, чтобы целостность не была критична. В самом деле, не критично, если на френдленте пост появится на пару секунд позже, нежели в блоге афтора.
Но даже при 10000 тредах большинство из них находится в состоянии ожидания. Проблема переключения контекстов отчасти решается при помощи Green Threads, когда N виртуальных тредов мэпятся в M нативных (M
Вообще все касается специфики апликации. Если мы разрабатываем рабочую среду, то да, нативный лук будет привычнее. А если же это, скажем, игра?
Кроме того, каждый день мы используем огровное количество сайтов, которые имеют совершенно разный дизайн и лук. И нас это не смущает…
1. Как передаются параметры при вызове от модуля к модулю: по значению (сериализация-десериализация), или по ссылке?
2. Как происходит резольвинг классов между модулями? Насколько я понимаю, каждый модуль имеет свой ClassLoader. И насколько я понимаю, delegation между ними не используется. Иначе когда модуль P недоступен, С не смог бы сделать резольвинг интерфейса I. То есть модуль C использует непосредственно классы из P или имеет собственную копию exported-пакетов?
3. А что будет если мы внезапно запустили новую версию сервиса P, которая поменяла интерфейс I и несколько экспортнутых классов? Если передача параметров идет по значению, то проблем не должно быть если классы остались serializable-совместимыми. Если же по ссылке, то возникнет ClassCastException, т.к. модуль C уже отрезольвил старую версию классов.
4. Я слышал, что можно одновременно иметь несколько версий одного и того же сервиса. И что consumer будет использовать именно последнюю версию сервиса. Можно ли как-нибудь динамически контролировать какую версию сервиса использовать?
5. Чтобы сделать unit-тесты для сервисов без испльзования OSGi, как я понимаю, очень несложно. Для этого нужно прописать соответствующие сервисы в тестовом spring context. А как делать автоматические integration-тесты в OSGi-контейнере? Есть какая-нибудь тулза?
Навскидку я не уверен, что Netty мне обеспечит:
— контроль длины и валидности входящих сообщений
— лимитирование коннекшнов с одного IP (против DoS)
— blacklist IP и сеток
— heartbeat, и автоматическое определение времени ping-а
— flooding-контроль
— remote-контроль валидности клиентского кода
— отсоединение неактивных клиентов
— если внезапно понадобится еще что — допишу
Другой недостаток библиотек — это синдром «черного ящика», когда не ясно как чужой код ведет себя при определенных условиях. Требует экспериментальных проверок, а иногда уже на production выползают очень интересные «фичи». Ну и естественно зависимость от производителя…
И все-таки причиной создания «велосипеда» было то, что он был написан, когда появился NIO (1.4.1). Netty и подобных фреймворков и в помине не было. Раньше были танцы с бубном, когда надо было обойти blocking io.
P.S. Про netty кстати не знал, спасибо. Хотя уверен, это не единственное решение (напр. Apache Camel).
С другой стороны, ситуация выправляется при помощи flexible layouts, когда элементы интерфейса могут тянуться пропорционально тексту. Кроме того, умные лейауты позволяют унифицировать размер группы виджетов по максимально необходимому.
Сообщений конечно же не 100, это я ошибся. 700 партий где-то по секунде-полторы на ход, то есть 500-700 сообщений в секунду. Обратный треффик больше: сообщение приходится реплицировать нескольким клиентам. В случае общего чата каждое сообщение или изменение графа отправляется всем пользователям.
Сервер разделен на 4 зала. Коннектор — отдельный процесс, который обслуживает все соединения с клиентами во всех игровых залах. Своего рода диспетчер пакетов и соединений. Интерфейс с серверами ввиде очереди сообщений через обычный Socket с блокирующим I/O. Сейчас, при 2000 пользователях он показывается в top с 7% CPU. Основное время тратится на шифровку/дешифровку пакетов.
4. Не совсем уверен, что корректно делать Select в одном треде, а обрабатывать SelectionKey в другом (ClientHandler). Мне кажется keys, они валидны только до следующей операции select, посему обрабатываться должны в том же треде.
5. Ваш сервер не обрабатывает отсоединение клиентов. Именно тут начнутся танцы с бубном. Наперед скажу, что не гарантируется, что для каждого отвалившегося клиента селектор вернет key.isValid()=false. Поэтому дисконнект нужно делать по IOException.
Кроме того, есть клиенты, которые при потере связи не пошлют TCP CLOSE-WAIT, и на сервере они останутся висеть бесконечно долго. Timeout возникнет только, если в буфере есть что послать клиенту. Поэтому чтобы такого не произошло, нужно пинговать клиента.