JavaScript, AJAX, Socket и Flash/ActionScript — исследуем вопрос передачи данных в AJAX-приложениях

[pixelcube]

Плюс ко всему прочему через Flash можно организовать одновременный upload нескольких файлов. С прогрессом.

[shuvalov]

хочу поправить — crossdomain.xml должен быть на запрашиваемоме хосте на том же порте, куда идет запрос данных. По крайней мере в FF3 у меня так.

[aleks_raiden]

да, именно так — на том хосте, к которому вы присоединяетесь, а не на том, откуда загружаете SWF-файл, вроде я так и написал :) По умолчанию ищется на стандартном HTTP-порту 80, но если нет — пробует специальный 843, это вроде как зарезервированный порт для запроса полиси безопасности

[shuvalov]

нет, я как раз про порт написал — у меня в FF3 политика такая, что куда я ображаюсь, с того же порта запрашивается политика. Не знаю какой уж стандарт(кстати, можно ссылку на него), но вот реализация такая у меня

[aleks_raiden]

очень странно, гм…
Ну вот описание хорошее — www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html
в частости, там есть о A fixed socket master policy file port, TCP port 843, that is consulted by default for socket policy files. This provides a standard way to serve socket policy files, rather than the «choose any port» system used previously.

Хотя… да, исследуя исходник в свн-е Java сервера я нашел там такой код, который детектит запрос для кросдоманина и возвращает его, либо перекидывает на обработчик сокета.

[shuvalov]

ну видимо либо у меня не 9ая версия, либо при отсутствии политики на 843 порту следует обращение к запрашиваемому порту

[shuvalov]

вот кстати еще один проект, правда более специфический — swfupload.org/. Вконтакте.Ру использует его.

[Gospodin]

Пока не появился 10-й флеш очень даже и рулил, но всвязи с новыми политиками безопасности приходится на странице расспологать флешовую кнопку что не очень красиво, хотя, что очень радует, подобную функциональность можно реализовать и с использованием Silverlight, причем без использования визуальных не-HTML элементов.

[Anatoly_Piskunov]

Но нужна поддержка Silverlight, да?

[Gospodin]

Да нужна поддержка, так-же как и у флеша, но в свете последних событий это не должно смущать.

[shuvalov]

в свете каких событий? А то меня что то поддержка флэша до сих пор смущает)

[Gospodin]

Активное продвижение Майкрософтом своей технологии + помощь Новелла на не-Windows платформах. Уже заметно как технология начинает обрастать мясом, но возможно пока еще рано говорить о каких-либо серъезных достижениях.

[vorbiz]

А ещё server push технологией владеют mongrel и juggernaut под rails

[efoxxi]

интересно, можно ли воспользовавшись одной из вышеперечисленных технологий реализовать torrent-клиент?

[KeepYourMind]

«А такая возможность надо уже сейчас!»

Исправте, пожалуйста.

[aleks_raiden]

что именно?

[Riddler]

надо -> есть

[KeepYourMind]

Лучше так: «А такая возможность нужна уже сейчас!»

Просто не звучит «возможность надо» как-то.

[Riddler]

Я вот ожидал увидеть простенький пример как вызвать функцию в ActionScript из JavaSctipt'a
Прочитал много текста и так ничего и не увидел… =(
А то как раз такая задача стоит… Мож знает кто?

[aleks_raiden]

да здесь и не должно было быть примеров, это исследование как и возможно ли.
Посмотрите исходники jSocket — там кода на строк 50, и все понятно вполне, как вызывается и как обьявляется

[sdmitry]

К вопросу о серверной части можно еще подумать о применении Open Source Flash Server по части Remoting и Shared Objects (правда раньше SO работали ненадёжно и грузили сильно сервер, сейчас не знаю). Это если на клиенте Flash.

[Pilat]

Мне кажется, с развитием Явы и увеличением скорости запуска апплетов все вопросы к JavaScript должны постепенно пропасть. Особого смысла писать на JS сложные приложения просто не останется.

[aleks_raiden]

это почему же? по моему они никак не связаны, кроме части в названии :)

[Pilat]

Потому что то, что на JavaScript делается сложно, медленно и ненадёжно, на Java делается просто, с визуальными построителями и кучей фреймворков. Единственная засада — сама Java очень пока неповоротлива. ExtJS как пример — чтобы сделать то, что сделали, пожертвовали производительностью, размерами, надёжностью, скоростью запуска. В сущности Java то же самое делает лучше и проще.

[aleks_raiden]

глупости :) покажите такое же на Java, без привлечения фреймворокв на сотню мегабайт :) JavaScript вполне устоявшийся язык, мощный и дающий во многих задачах фору остальным. а Java это совсем другое. очень другое.

[Pilat]

Swing — это не оно?

[aleks_raiden]

нет

[Pilat]

Типа на JavaScript плохой программист вдруг становится хорошим? Не верю.

[ginius]

Для Ruby on Rails есть решение Juggernaut. Хотя для конкретных ситуаций может потребовать доработки.

[kandreev]

Заворачивайте свой протокол в HTTP.

Это позволит избежать проблем с доступом из всяких неожиданных мест,
таких как интернет-кафе, отмеченные выше офисы и т.п.

[aleks_raiden]

это не всегда возможно, часто накладные расходы на HTTP слишком велики + его неприспособленность к длительным соединениям (то есть его сессионная природа является минусом)

[isapioff]

эм…

Осознавая давно уже ограниченность возможностей XMLHTTPRequest (думаю, если у вас есть опыт разработки, то вы знаете о каких ограничениях идет речь)

так кто вас ограничивает? можно подробней?

далее… держать открытые соединения на большом проекте — никаких можностей не хватит. как вы будете это решать?
каким образом вы хотите обойти файрволы и прокси, как справедливо заметил vectart?
вы читали это: en.wikipedia.org/wiki/SOAP?
вы понимаете для ЧЕГО это было сделано?

[aleks_raiden]

ограничения объекта и протокола. невозможность работать на других портах, передавать и принимать другой протокол кроме HTTP, отсутствие кроссдоменности и много еще чего.

Почему не хватит, зависит от проекта, количества и задачи. 20 тыс соединений открытых например это много или мало? держится нормально.

Прокси и фаерволы либо не будут обходится, либо проксирование через 80 порт, либо просто предоставление клиенту урезанной версии, если полная не работает. зависит от задачи.

Читал про SOAP, знаю, также знаю много других умных слов — XML-RPC, Hessian, Burlap, WebORB, ICE и что? вы представляете применение соапа и характер задачи, коорую решаю я через это исследование и какие можно им решить?

[isapioff]

> 20 тыс соединений открытых
— это довольно много. реализовать правильно работу с таком количеством соединений не просто

>вы представляете применение соапа и характер задачи, коорую решаю я через это
> исследование и какие можно им решить?
— нет, не представляю.

[aml]

Мы в нашей игре (http://www.magiclands.ru) использовали технологию, которая в статье названа long poll. Работает очень быстро и устойчиво. Открытые соединения проксируются на несколько бэкендов, каждый из которых обслуживает свою часть юзеров. Масштабировать можно практически неограниченно, добавляя сервера и процессы и распределяя по ним пользователей.

Практика показала, что нагрузку создает не число одновременно установленных соединений, а количество новых запросов в единицу времени. В населенных локациях народу ходит много — постоянно много данных отправляется всем, кто там находится — нагрузка возрастает.

На гейм-дизайнера ложится задача минимизировать такие скопления, а в целях борьбы с перегрузками введена саморегулирующаяся задержка, которая не сразу закрывает соединение при поступлении данных, а ждет ещё какое-то время — вдруг ещё что придёт на отправку, и уже после этой задержки отправляет пакет. Для системы это в разы снижает нагрузку, а для игрока выглядит, как задержка между отдачей команды на перемещение и началом движения. Если сделать, что собственные действия никогда не задерживаются, а действия других персонажей можно и притормозить, то игроки задержку и замечать не будут.

В чате секундная задержка практически незаметна пользователям и позволяет комфортно общаться.

[aleks_raiden]

очень интересно, спасибо! а какой софт на сервере? это java-севера или как?

[aml]

На фронтенде nginx, бэкенды, который этот long poll реализуют, на C++. Остальная логика игры — Perl со вставками C++, где время выполнения критично.

[maashaa]

О том, кто и насколько поддерживает HTML5 WebSocket можно будет почитать в Википедии. Пока же для желающих использовать WebSocket интересной опцией является KAAZING.