В Http изначально не предусмотрен механизм callback. Поэтому единственное что приходится делать — это периодический полинг и по возможности задерживать ответ http настолько насколько это возможно, оставляя коннекшн открытым. Дело усложняют корпоративные proxy, которые имеют собственное представление о запросах, времени ожидания и т.д… Как показывает практика, сервисы типа google talk и icq по http из корпоративного окружения работают вон плохо. Наши прокси, например, закачивают response, прогоняют через корпоративный антивирь и после этого отдают клиенту. Понятно проблематично будет использовать http streaming.
С развитием модели клиент-сервер должны развиваться и приложения которые вклиниваются между клиентом и сервером: proxy, фаерволы, антивирусы и т.д. Ну и конечно админы :-)
иначе будем стоять на месте
Мне кажется, что самое просто решение для обратного вызова, это небольшой flash-апплет на клиенте.
Flash уже давно умеет работать с обычными сокетами, а так же взаимодействовать с JS в браузере, передавая ему событие и его данные. Почему бы не поручить ему эту часть работы.
На другой стороне может быть любой простейший socket-сервер.
Круто только вот по моему серверы которые выдерживают 500000 запросов за нное количество времяни в раз эдак сто меньше выдержат клиентов подключенных за нное количество времяни, вопрос за чем так рисковать оборудованием и пользователями веб сайтов, ради первых подключенных?
Конечно круто, конечно здорово но, в в вебе оно лишнее, видь веб в приципе это большая доска обьявления которою должны просматривать люди а не к которым должна она сама приходить, хотя я и не против был бы, но вот опять и тут минус, мне надаест разнозчик этих обьевлений, а в вебе мне надоет постоянный конект с сервером.
Глянул через Firebug
Реализация проста — с начала работы скрипт «устанавливает сессию», после чего отправляет запрос на сервер. Ждёт одно из следующих событий:
1. Обрыв соединения
2. Получение данных
В любом из случаев он сразу повторно открывает соединение!
Во втором случае — ещё и совершает действие, основанное на полученных данных
Я не совсем понял, кто-то тут еще писал про дуплексные сервисы — вы listeners-сокеты открываете на клиентской стороне? А как быть тем, кто за NAT сидит?
Вообще, у меня вот ADSL модем и я сижу за NAT, на всех работах локальные сети за NAT — опять же — всякие устройства и гаджеты в мобильных сетях… Сложно представить даже количество людей сидящих за NAT или хотя бы firewall'ами. Вы включенный стандартный firewall Windows учли?
Кто такие вы?
Счетчики определяют. Не 100% точно (бывает что разными браузерами один человек пользуется или один браузер, но был реконнект в ходе которого был выдан новый ip), но это достаточно чтобы сказать, что на данный момент людей, что сидят за натом полно. Это и большие конторы и домосети и всякие студ. общаги где сотни и тысячи посетителей могут 1 или несколько ip использовать.
Ужс, неужто вы думаете что NAT пользователей лишь маленький процент?
Пускай, правда, что провайдеры дабы упростить себе жизнь начали выделять юзерам реальные айпишники, но как насчёт юзеров у которых дома Wi-Fi роутеры? Таких становится всё больше и больше.
Я сейчас сижу за ADSL-модемом. У меня внешний IP-адрес (пусть и динамический), внутри моей домашней подсети один компьютер. Я и посетитель и хост. Но к моему браузеру вы не пробьетесь пока я в модеме правила не настрою.
Я у скольких включен firewall под Windows — как creotiv собрался его включать? Неужели из набора секретных команд Javascript'а?
Уже в двух проектах использовал DWR, очень хорошо вписывается в архитектуру J2EE. Против всяких прокси используется Early Closing Mode. Остался доволен.
Если уж всё равно предлагается ставить ПО на сервер, то почему на костыли-то (HTTP)? Тогда уж полноценные сокеты открывать и на клиенте через флеш работать.
«Я как бэ не понял» (с), разве порт 6969 не является де-факто портом BitTorrent-трекеров? Или с появлением php'шных трекеров их вешают только на 80-ый порт? :)
Пообщался с автором по поводу поддержки не-линукс систем, если кому интересно:
Alexey Ivanov a écrit:
> > Are you planing to add support for non-epoll systems like FreeBSD and
> > Solaris by using kqueue and /dev/poll on that OSes?
> >
> > —
> > Sincerely y0uRz,
> > Alexey Ivanov
Hi Alexey,
Since kqueue et /dev/poll work on the same way than epoll, porting APE
to such OS could be pretty easy.
This will may be happen on the 1.0 release ;)
Пуш ми, бум-бум, тач ми… Ajax Push Engine