Да понимаю я это все...
Написал уже. После суток ожидания дали ссылку на документацию -_-
Этот вопрос просто уже крик души... Последняя попытка так сказать...
$('.addToCart').on('click', addToCart() );
Оно случайно не дает у вас одно ложное срабатывание при загрузке данного кода?
Вы при передаче функции вызываете ее
Должно выглядеть вот так: $('.addToCart').on('click', addToCart);
То бишь функции мы передаем без скобок
Ivan Bogachev, конечно не сможет
Но обычно когда делают крутые эффекты на canvas, там получается фигова туча элементов
И dom уже такое не вытягивает :(
Чего-то я не улавливаю суть
Это же не конкретика, а теория, то что вы предлагаете
Есть сервер, который выдает информацию
Есть клиент, который читает ее
file_get_contents, XMLHttpRequest или что-то еще
Вы советуете очень общие вещи
У меня уже есть сервер, который выдает JSON при http запросе
Теперь мне просто нужно получать этот JSON
Причем с помощью JS, а не PHP
Но XMLHttpRequest не подходит (в вопросе я описал причину по которой он не подходит)
Вот я и пытаюсь найти аналог XMLHttpRequest, но чтобы он не вызвал таких проблем
Увы это совсем не подходит
Они и так ругаются на то что не безопасно
А тут вообще получаются внешние скрипты, а не JSON
Они меня вообще сразу же за такое в чс внесут XD
res2001, а что с играми по RDP не так? Временной лаг? Если да, то это вообще меня не волнует
Вопрос не в качестве использования, а именно в удобстве
Чтобы приложения у одного пользователя не вылетали, когда другой решает ими воспользоваться
Это гораздо критичнее, чем временные лаги
Я не совсем понял с виртуализацией
Насколько я понимаю, это виртуальные машины запускаемые в рамках основной ОС, правильно?
Просто я пытался решить задачу с помощью Virtualbox, VMware, Hyper-V, но как я уже писал выше, наткнулся на проблемы с поддержкой DX11
А чем меня RDP привлек, так это тем что RDP позволяет запустить параллельно несколько пользователей на основной ОС
И нет никакой возни с поддержкой ПО
+ по ресурсам намного экономичнее получается чем с виртуальными машинами
Поэтому я решил попытаться изолировать активных пользователей системы друг от друга
Мне кажется что это должно довольно легко решаться и ограничено политикой, а не архитектурой
Нет, речь идет не о Скайпе, а о программах, которые не допускают повторного запуска себя
Скайп был взят чисто для примера
Цель - полноценная работа двух пользователей на одной машине (скайп, браузер, игры и т.д.)
Я пытаюсь найти полноценное решение
А как вы понимаете заглядывать в каждую программу проверяю как она узнает что не одна в системе - это костыли
Если начинает использоваться какая-то новая программа, также не любящая двойного открытия, то придется править костыль под нее
Это очень не удобно
sandboxie не удобно, да и не получится - некоторые программы категорически против запускаться в такой среде, распознают :)
Под виртуализацией имеете ввиду программы типа Virtualbox, VMware, Hyper-V?
Если да, то я столкнулся с проблемой запуска игр. Жалуются на отсутствие DX11 (поддержка DX11 только у Hyper-V, но какая-то кривая). Так что тоже не вариант
Или я не правильно понял что вы предлагаете сделать под словом "виртуализация"?
Не кастомизированное ядро Linux при нормальных сетевых картах выдаёт порядка 300'000 pps или около 4 Гбит/с. У тебя довольно хорошая программа на Яве. С таким интенсивным трафиком может не справляться ядро.
Так я и не знаю справится ли Java программа. Я ее не тестировал. Она просто есть опенсурс. Но у меня есть сомнения что она сможет обработать столько трафика. Там тупо используется либа от Netty.
Спасибо за ответ!
Уже появилась идея как можно реализовать систему в рамках моего проекта, чтобы система была отказоустойчивой и надежной
1) С одного клиента может идти от 7 до 200 пакетов в секунду. Система рассчитывается на онлайн в 10к юзеров. То есть получается до 2.000.000 pps. Я конечно не специалист, но мне кажется что это дофига :) Даже если не брать максимум, а какой-нибудь средничек в 500,000 pps
2) Так нет пока нагрузки. Просто здравый смысл подсказывает что Java программа не выдержит и ляжет. Вообще она рассчитана на 100-200 юзеров, а как я указал выше, система затачивается под чуть большее количество. Вот я не верю что Java программа будет стабильно работать и за неделю ни разу не накроется. Вот не доверяю я Java... Так что надо писать нормальную систему. А раз переписываем, то почему бы не спросить совета у умных людей и не сделать как надо?
3) Вот я как раз и думаю о высокой доступности и надежности. Если отвалятся все пользователи разом это будет очень, очень плохо. Так что, как я уже сказал, советы умных людей и грамотный подход к вопросу :)
Просто меня очень напрягает это "узкое горлышко", которое создает клиент своей особенностью соединения с сервером. А клиент модифицировать нельзя. Поэтому нужно это самое горлышко сделать максимально надежным, так как получается что это самое уязвимое место в системе...
Дмитрий Шицков, там все зависит от важности пакета. Если это тупо пакет перемещения игрока, то конечно это будет всего лишь лаг. А если в этот момент будет переключение кодировки пакетов, то тогда увы кранты соединению. Как я уже говорил, так очень криво написан клиент. Я полагаю что изначально не рассчитывалась игра на сервера. Возможно небольшие частные серверы на 10-20 игроков.
А система VRRP как-то учитывает доступность haproxy? Был ли принят пакет? Или просто учитывается онлайн маршрутизатора?
Дмитрий Шицков, по сути соединение это тупо шифрованный текст, который отправляется на определенный ip+порт. После того как пакет приходит в центральный узел, он декодируется. В пакете содержится никнейм игрока. Далее узел сверяет по таблицам на каком сервере сейчас находится игрок и отправляет данные из пакета на соответствующий сервер. Так что передавать между центральными узлами информацию о соединении не составит труда.
Мне больше не понятна ситуация как при попадании пакета в ip+порт он может быть отправлен на один из нескольких серверов (центральных узлов). Вот как сделать чтобы попадая в порт, пакет отправлялся на работающий центральный узел и при этом не потерялся. Как я понимаю haproxy - это один сервер, который будет перекидывать пакеты на другие сервера (центральные узлы). Так? И получается что у нас в любом случае будет место, где принимающий сервер один. Так? Я просто на всякий случай уточняю, чтобы убедиться что я все до конца понимаю.
Понятно что нужно переписывать это шлако-клиент. Но увы клиент невозможно переписать. Так что приходится работать с тем что есть и пытаться выжать максимум стабильности из изначально нестабильной архитектуры :(
Не совсем так
При подключении, пользователя забрасывает на главный сервер. Далее по желанию пользователя он может перемещать между серверами.
Но с технической точки зрения для клиента существует только один сервер - центральный узел (та самая Java программа). А этот узел уже передает пакеты к тому серверу, который выбрал пользователь.
Просто клиент написан очень криво и не умеет переключаться между несколькими IP или портами. Он как создает соединение, так соединение и есть. Поэтому и нужен этот центральный узел, чтобы перекидывать это самое соединение между серверами.
То есть получается что все зависит от центрального узла. Рухнул центральный узел - пакеты не могут доставляются серверам. И как следствие все игроки вылетели из игры. Я пытаюсь избежать такой ситуации.
Написал уже. После суток ожидания дали ссылку на документацию -_-
Этот вопрос просто уже крик души... Последняя попытка так сказать...