var con = new ActiveXObject("Microsoft.XMLHTTP");
con.open('127.0.0.1:79',"GET",true);
alert(con.readystate); \\ 1
con.send(' '); \\ тут возникает ошибка, а когда я переношу этот код на сервер, то всё нормально работает, AJAX же вроде с другого хоста не работает...
alert(con.readystate) ;
прямой коннект
Здравствуйте уважаемые программисты, у меня есть один вопрос к вам: у меня есть отдельно клиент, отдельно сервер,как мне осуществить прямой коннект между ними, по сути я решил эту проблему, тока, как обычно через ... да нет не о том подумали через actionscript, а это очень не удобно, при этом я использую ФЛЕШЬ тока для соединения.
Так в чём проблема-то? Flash не нравится?
Да , очень не нравиться:)
Цитата: smoki
Да , очень не нравиться:)
А как насчет запуска Ajax по таймеру с периодичностью в 0.5 секунды. Такое понравиться?
AJAX же вроде может создать постоянный коннект, ну по крайне мере, я пробывал.
Код:
Тема поднималась уже много раз. Запрашивайте Ajax-ом свой хост, а со своего хоста уже запрашивайте данные с другого хоста. Так все будет работать.
А насчет постоянного соединения с помощью Ajax: сделать можно, но не всякому хостеру понравятся часами висящие соединения. Хостер может принудительно закрывать такие соединения после какого-то времени после открытия.
А насчет постоянного соединения с помощью Ajax: сделать можно, но не всякому хостеру понравятся часами висящие соединения. Хостер может принудительно закрывать такие соединения после какого-то времени после открытия.
Если речь идет о постоянном соединении - AJAX тут не поможет (он работает на основе протокола НТТР). Тут вам либо Flash (наилучшее решение), либо JavaApplet (требуется установка JVM), либо ActiveX (который будет работать только в IE).
Цитата: smoki
AJAX же вроде может создать постоянный коннект, ну по крайне мере, я пробывал.
Ты что-то путаешь. В браузере объект XMLHttpRequest будет убит самим браузером по таймауту, а серверный скрипт по таймауту также, но уже веб сервером.
Дело не столько в таймауте сколько в самом протоколе НТТР который работает по принципу "Установка соединения - запрос - ответ - разрыв соединения"
Цитата: alekciy
Ты что-то путаешь. В браузере объект XMLHttpRequest будет убит самим браузером по таймауту, а серверный скрипт по таймауту также, но уже веб сервером.
Ну может на счёт AJAX я с тобой и соглашусь, но на счет серверного скрипа... Ты хочешь сказать, что сервер закроет мне сокеты, через определённое время или, что ты имел ввиду? Если про сокеты, как сервер сожет мне их закрыть?
сервер может закрыть процесс скрипта а вместе с ним и открытые им сокеты =)
по таймауту
не на всех хостингах разрешен set_time_limit(0);
по таймауту
не на всех хостингах разрешен set_time_limit(0);
Ага, RussianSpy дело говорит. Уже даже более усугублю: не то что на всех не стоит, на большей (дедики не считаем, на то они и дедики ;) ) части таймаут установлен. Если еще точнее, то я не знаю пока ни одного хостинга который бы дал поставить set_time_limit(0).
Цитата: RussianSpy
Дело не столько в таймауте сколько в самом протоколе НТТР который работает по принципу "Установка соединения - запрос - ответ - разрыв соединения"
Нет, дело именно в таймауте браузера. Знаю как минимум один работающий проек в котором серверная часть соединение не закрывает вовсе, а просто "досылает" данные. Очень похоже на открытие здоровой фотки через модем :D .
Так вот им там пришлось XMLHttpRequest постоянно пересоздавать, т.к. браузер по таймауту прибивал его. А сервер как не закрывал соединение, так и держал его все время пока подключеные клиенты в таймаут не вылетали.
Цитата: RussianSpy
Дело не столько в таймауте сколько в самом протоколе НТТР который работает по принципу "Установка соединения - запрос - ответ - разрыв соединения"
Хочу напомнить, что HTTP/1.1 как раз не разрывавет соединение после ответа, а может держать его.
Хотя в целом согласен - не чего исспользовать для решения задачи то, что для этого не предназначенно. )
Цитата: aks
Хочу напомнить, что HTTP/1.1 как раз не разрывавет соединение после ответа, а может держать его.
А как это реализуют то? Я вот знаю, что да, делают, а как самому любопытно. Точнее даже так, в упомянутом мною проекте на сервере использовали Java приложение. А вот можно ли реализовать не разрыв соединения в том же Apache? Т.е. что бы из PHP скрипта досылать данные в браузер по постоянному соединению и постоянному 80-ому порту. Как я не прикидывал, так и не догадался, можно ли на PHP так сделать.
Цитата: alekciy
А как это реализуют то?
Первый вариант: http://ajaxpatterns.org/HTTP_Streaming
Второй вариант. Если немножко подумать зачем может быть нужно такое соединение, то только для оперативного обмена данными между сервером и клиентом. Если кто-нибудь может мне сказать другие причины - буду рад услышать. Так вот, такой обмен данными можно создать и с помощью регулярных соединений с сервером (например раз в 5 секунд) на том же многострадальном Ajax-е. Если на сервере использовать какое нибудь хранилище данных для сообщений то все это можно сделать достаточно просто. Этот вариант я уже предлагал, но топикстартеру он почему-то не подошел.
Хотя я полностью согласен с людьми которые говорят, что по сути сама задача - издевательство над основами веба.
Цитата: shine
Первый вариант: http://ajaxpatterns.org/HTTP_Streaming
Почитаем. Не факт, что с ходу врублюсь.
Цитата: shine
Второй вариант. Если немножко подумать зачем может быть нужно такое соединение, то только для оперативного обмена данными между сервером и клиентом. Если кто-нибудь может мне сказать другие причины - буду рад услышать.
Если более конкретно, то чат. Посмотри на тот же chat.chat.ru
Цитата: shine
Так вот, такой обмен данными можно создать и с помощью регулярных соединений с сервером (например раз в 5 секунд) на том же многострадальном Ajax-е.
В том и дело, что как это все сделать используя Ajax насвязке PHP+JS я отлично знаю. Я не могу заставить серверный скрипт "досылать" данные. Т.е. прошло соединение, по нему прошло 2-3 сообщения, соединение не разывается, но сервер молчит, а клиент ждет. Потом появились новые данные, сервер их в отрытое соединение достал и т.д.
Цитата: alekciy
В том и дело, что как это все сделать используя Ajax насвязке PHP+JS я отлично знаю. Я не могу заставить серверный скрипт "досылать" данные. Т.е. прошло соединение, по нему прошло 2-3 сообщения, соединение не разывается, но сервер молчит, а клиент ждет. Потом появились новые данные, сервер их в отрытое соединение достал и т.д.
Почитай ссылку про HTTP_Streaming. Там как раз рассказывают как такое делать. Хотя все эти постоянные соединения это страшно некошерный способ :D
Цитата: alekciy
Почему?
Гемороя много(память апача + число соединений + таймауты), а преимуществ по сравнению с Ajax ты получишь мало. Кстати, разработчики XAJAX обещали включить свою реализацию HTTP_Streaming в свой ближайший релиз(0.5). Сейчас у них уже было несколько бета-версий, так что может скоро и розродятся. Тогда не прийдется придумывать велосипед.
Цитата: alekciy
А как это реализуют то? Я вот знаю, что да, делают, а как самому любопытно. Точнее даже так, в упомянутом мною проекте на сервере использовали Java приложение. А вот можно ли реализовать не разрыв соединения в том же Apache? Т.е. что бы из PHP скрипта досылать данные в браузер по постоянному соединению и постоянному 80-ому порту. Как я не прикидывал, так и не догадался, можно ли на PHP так сделать.
досылай в цикле клиенту <!-- --> оно благо и в браузере не отображается =))))))))
а как только пришли новые данные пиши их =) делал я так где-то, но только на Perl и для того чтобы браузер в ожидании не отсох (не больше минут 5ти такое соединение держалось... надо было так :P).
PS: да и в перле есть замечательная штука $! (вывод идёт сразу не дожидаясь пока наберется блок в N байт для посылки :) ) :) а в PHP не знаю как такое реализовывать
Цитата: shine
Гемороя много(память апача + число соединений + таймауты), а преимуществ по сравнению с Ajax ты получишь мало.
В том и дело, что преимущество есть. Это трафик и уменьшение запросов. При чистом аяксе получается что клиенты тергают сервер каждые Х сек. Пусть даже каждые 2 сек... 50 клиентов к примеру... это сколько соединений в секунду? Многова-то ибо вполне может статься, что установка соединения была бесполезной и новых данных нет. А тут у нас соединение уже есть, накладных расходов на установку нового соединения уже не нужно. Насчет памяти... ну в наше время это не проблема + у нас же на сервере висит демон который в принципе занимает практически одно и тоже количество ОЗУ.
Цитата: Тень Пса
досылай в цикле клиенту <!-- --> оно благо и в браузере не отображается =))))))))
Ну первое это то, что отображаться то не отображается, однако трафик то идет. И второе. В PHP у меня так не получилось. Т.е. данные на клиент уходят когда скрипт полность отработал логику. А до тех пор данные не идут. Пытался через буферизацию намутить, но не вышло.
Во народ гемороится))) Сказали же, флэээээш)))). Он под это УЖЕ заточен и "снисходителен" к серверу, а то, что вы ту мутите как правило для небольших проектах применимо (побалываться, "азм смог"(с))))), а для крупных... Изврат это))))
Гы.... ну мы с тобой уже перетерли :D не люблю я флеш... не люблю...
Цитата: shaelf
Во народ гемороится))) Сказали же, флэээээш)))). Он под это УЖЕ заточен и "снисходителен" к серверу, а то, что вы ту мутите как правило для небольших проектах применимо (побалываться, "азм смог"(с))))), а для крупных... Изврат это))))
Да, проанализировав всю вашу дискуссию и почитав http://ajaxpatterns.org/HTTP_Streaming, я понял что лучше Flash, в следствии вновь открытого у меня возник ещё вопрос:D :Вы говорите что серверный скрипт может быть закрыт по тайм-ауту следовательно будут закрыты и Socket`ы, получается так, что будет релизовано постоянное соединение, которое будет закрыто, и даже если я заставлю клиент реконектиться, всё равно не смогу т.к socket`ы закрыты? Весело, так, и как мне тогда заного оккрыть Socket или как можно проверить закрытие их?
Цитата: smoki
:Вы говорите что серверный скрипт может быть закрыт по тайм-ауту следовательно будут закрыты и Socket`ы
Одно дело будет закрыт скрипт, который был вызван по веб сервером HTTP запросу. А черз сокеты надо уже коннектиться к своему серверу (пусть и написанному на том же языке), который постоянно запущен и никогда кроме аварийных случаев не закрывается.