вот это и было первое мое решение, которое пришло в голову когда еще вопрос не запостил. но после обсуждения тут, понял насколько оно сырое. нам не нужно передавать сами данные клиенту, достаточно передавать только состояния датчиков которые соответствуют этим данным. в итоге буферизация не нужна вообще, все данные на лету парсяться на сервере, в клиент передается инфа только о том что нужно изменить. ну а передавать эту инфу уже можно по разному, хоть вебсокеты/флеш(самое оптимальное в плане нагрузки на клиента имхо), хоть ежесекундные http-запросы(больше всего нагрузят и клиент и сервер), хоть long-polling/comet…
что мешает представить эти данные в виде бесконечного «длинного файла»? и яваскриптом на лету парсить и отображать? другое дело что это совсем не оптимально, из обсуждения я пришел к выводу что лучше всего будет парсить поступающие данные сразу на стороне сервера, при первом показе страницы переслать всю «картину» клиенту и отобразить, а потом посылать только данные о внесении изменений. тоесть на сервере проверка показала что датчик из зеленой зоны перешел в желтую — сразу отправляем эту инфу клиенту, инфу о остальных датчиках не отправляем если ничего не менялось. В таком случае можно использовать long-polling как мне кажется, «цвет» датчиков будет сменятся не так часто. Кстати работать это будет в гигабитной локалке, такчто думаю и в 100мс даже сплошным потоком эти данные бы укладывались:) Но смысла напрягать клиентский браузер не вижу.
Пожалуй уточню, я знаю как решить эту задачу стандартными средствами(AJAX, long polling, передача клиенту только изменений индикаторов, без передачи самих данных). И благодаря комментам ниже я уже сообразил как обойти большинство «затыков/граблей» о которых я думал изначально. Спасибо за это. Но я не зря в тегах и вопросе упомянул HTML5 — мне очень интересен практический опыт тех кто уже делал что нибудь с использованием новых возможностей. Конкретнее интересует их мнение по поводу того стоит ли применять эти технологии в данном случае, насколько сложно в них разобраться с нуля, будет ли это решение менее ресурсоемким или может более быстрым, отзывчивым? Ну а те кому не лень читать мои простыни текстов могут в комментах ниже посмеяться над тем как я вначале тупил, к каким выводам пришел и поправить меня если где-то не прав или есть более оптимальный метод.
фрейм хрома можно даже в ие поставить… но мне больше нравится функция хрома — Создать ярлыки приложений, выглядит практически как отдельное приложение, работает быстро, не зависит от других запущенных копий хрома. Да вебсокеты для меня самое удобное решение, посмотрим как выйдет с реализацией.
та я уже понял что желание клиента это хорошо, но все же нужно в разумных пределах реализовывать. буду анализировать данные на серверной стороне и посылать клиенту только изменения состояния датчиков, так и перерисовывать страницу не нужно будет тысячи раз и данных передаваться лишних не будет. проблемы нагрузки в таком случае практически не будет.
ряби не будет просто потому что данные будут соответствовать всего нескольким цветам и 95% времени данные по конкретному датчику будут на одном уровне — тоесть спрайт не будет менятся, сам только что сообразил что это значительно снизит нагрузку на клиентской стороне — перерисовывать придется только изредка.Для наблюдателя это будет выглядеть как стенд светодиодов: горит зеленым — все в норме, горит желтым — нужно проверить, горит красным — срочно чинить, черный — деталь накрылась… както так, только у зеленого и желтого будут дополнительные градации.
ну а за то что вебсокеты пропадут из стандарта я не переживаю — это очень маловероятно. java/as мне однозначно не подходят — не люблю эти языки, потому не слежу и не вникаю — а значит и толкового ничего не сделаю. потому наверно будет утилитка на С(которая генерит данные)+ питон(в крайнем случае пхп) на сервере+js/jquery на клиенте.
Теперь общая картинка уже вырисовывается, но мне все еще интересно мнение тех кто разрабатывал «отзывчивые» интерфейсы(например у хтмл5 игрушек) с использованием канваса: на сколько сложно разобраться сначала, насколько быстро изменяется «полотно», насколько сильно это напрягает комп.
вы похоже не уловили почему мне кажется эта идея неверной, все чаты и иркморды в том числе обновляют страницу не так уж часто, потому без проблем работают, а в моем случае нужно успевать угробить старые данные и показать новые за доли секунды, но даже если «схитрить» и обновлять раз в секунду то представьте что будет если на странице сотня датчиков(страховаться от такого думаю табами с небольшими группами датчиков)
этот способ я знаю, но я не уверен что он тут к месту частота смены данных будет очень большая — скорее всего 50-100мс. вы уверены что броузер не загнется обрабатывая 10-20 хтмлреквестов в секунду и рендеря новую картинку? Я конечно уже подумал о том что намного удобнее делать собирать данные в небольшие блоки, получать среднее значение а страницу обновлять раз в 5 секунд. естественно учитывая все аномальные результаты в таких блоках, но заказчик хочет «прям вот риалтайм отображение всех данных» — даже если человек на глаз их различить не успеет. Ну и так как это не для широкого круга пользователей то можно не ограничивать себя в выборе броузера, потому я сразу и подумал о хтмл5 — использовать сокеты для обмена данными(скорее всего понадобится двухсторонний обмен — на сервер нужно будет передавать команды запуска/остановки/изменения параметров), а на канвасе например рисовать «карту» датчиков — по идее это значительно быстрее чем изменение DOM. Вот только практического опыта нет — хотелось бы выяснить стоит ли счас в попыхах подучить хтмл5 ради более качественной реализации, или делать по старинке потому что выигрыша не будет.
он только вышел, так что выбор не большой. я пока видел только на www.dhgate.com/wholesale/meizu+m9.html, сам оттуда еще ничего не заказывал. но думаю в ближайший месяц-два все таки решусь — в наши края его все равно если и дождешься то за 700-800 баксов
вы не правы, много где есть свои декодеры(хоть и не для всех форматов). и еще от того что в плеере используется opensource ffmpeg сам плеер не обязан быть опенсорсным, просто на сайте должен быть линк на исходники ffmpeg, но аж никак не плеера. И даже если их нет — пользователь ничего не нарушает, все претензии должны быть к автору плеера.
все зависит от вайфай сетевухи которая там стоит, если она умеет работать в режиме AP(точки доступа) то проблем с подключением нескольких клиентов не будет. Ну а расшарить интернет средствами винды проще простого — достаточно в свойствах сетевого подключения куда приходит инет выбрать общий доступ(последняя вкладка) и указать там свою вайфай сетевуху.
не факт. если делать игру именно как рпг с возможностью управления как кораблем так и персонажами то понадобится скорее 2 движка: один отвечающий за «космос» полеты на корабле, отрисовка галактик итд, а второй уже за рисовку локаций внутри кораблей, на планетах в общем везде где можно играть персонажами.
