Здравствуйте дорогие форумчане!

У меня возник вопрос, необходимо между двумя запущенными скриптами создать обмен информацией. Каким образом это можно реализовать не прибегая к сокетам, поскольку на конечном сервере сокетные пхп соединения запрещены, и как это сделать не прибегая к обмену через файлы, и коль уже нельзя иначе, чем ререз файлы, как сделать так, чтобы скрипт реагировал только тогда, когда в файле новые данные поступили.
Есть ли идеи реализации? Буду очень прекрайне благодарен за наводку.

Далее вопрос номер два, скрипт подаёт данные на скачку, предположим какой нибудь файл, мне очень крайне важно контроллировать скорость этой передачи, чтобы та не превышала опеределённого значения заданного мною. Можно ли и это сделать? Именно скажем, чтобы данные не поступали быстрее одного байта в секунду, предположим. И за решение этой задачи буду прекрайне благодарен.

вопрос об ограничении скорости отдачи вынеси в новую тему. 
обсуждение двух вопросов в одной теме - это будет бардак.

скрипты запущены на одном домене? или же вообще на разный хостинг-площадках?

 Купить платный хостинг.

 Да. Паузами.

Да, они запущены на одном домене, даже лучше сказать, что это один и тот же скрипт запущенный двумя пользователями, как обменяться между ними информацией, если предположим у скриптов неограниченное время запуска.


Плохой совет, ещё идеи?



Но паузами будет ведь не совсем то, или? Какой это контроль за скоростью, если данные будут рывками передаваться, но с полной скоростью.

Смотрите в область Семафоров и мютексов (этого в пхп нет, придется самому реализовывать).
http://ru2.php.net/manual/en/book.shmop.php
http://ru2.php.net/manual/en/book.sem.php

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


В PHP никак, т.к. доступ к другим ресурсам напрямую, как пямять, у PHP закрыт.


Это сообщение отредактировал(а) Mal Hack - 25.7.2009, 14:15

Viroman, О каких скоростях/реактивностях обмена информацией идет речь? Чем не устраивают простые реализации chat'ов?
Все, что немного посложнее/побыстрее/пореактивнее - требует открытых портов и отдельного гемороя с настройкой соответствующего софта.

Для частной задачи общения специально подобранных юзеров можно написать Java аpplet, ActiveX или еще какую фенечку...

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

Viroman, ksnk, вы мой пост видели? 

Mal Hack, спасибо большое, буду разбираться, единственное что пока хотелось бы, это простите за наглость, именно пример такого использования. Я конечно понимаю, если самому велосипед изобретать, но надеялся на пример готовой реализации. Спасибо большое, я буду разбираться.

Примера дать не могу, т.к. сам такую реализацию на PHP не писал.
Глобально, смысл такой. Что юзайте shared memory по аналогии с общим файлом. Тут проблем быть не должно.
Что касается симафоров и мьютексов, то тут надо "вкуривать". Неплохой пример объяснения что это вообще - тут: http://doc.trolltech.com/4.5/threads-semaphores.html, правда не на PHP.
Про мьютексы тамже.

Скорость надо файрволлом шейпить, а не на PHP. 

А относительно обмена могу предложить только не лучший вариант с БД.

Отличный совет. Решает сразу и второй вопрос.



Купить платный хостинг. Ограничить скорость на уровне системы. А вообще зависит от способа, которым Вы реализуете "общение" между процессами.

Если у вас там, как говорите, тысячи клиентов онлайн - неужели не будет средств на выделенный сервер? Или Вы очередной халявщик, желающий сэкономить как можно больше копеек?

Как вариант дешевого способа решения задачи (хотя не много не оптимального), могу посоветовать SOAP.

Автор теоретик просто.
Ну не знает, что нельзя 1k видео онлайн на фри хостинге сделать)

Ни первый, ни второй, никакой вопрос это не решает, у меня и так платный хостинг. Знаю, что его можно сменить, но я может это смогу сделать, а второй, третий жаждущий итп, нет.



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


Не вопрос, чем надо шейпить, а что возможно, надо будет, можно и копытами шейпить, однако не решение. 
Насчёт БД, вот представьте ситуёвину.

Два физических клиента стучатся на внешний php скрипт(находящийся на одном и том же хостинге), стучатся они на неопределённое время, один стучится с намерением аплоадить, то есть посылает на вызванный скрипт нескончаемое количество информации, которая поступает время от времени(рывками, а может залпом, неважно, но постоянно, при этом максимальное время работы скрипта упускаем пока из виду, представим, что оно бесконечно), а другой наоборот, стучится к скрипту с намерением скачать с этого скрипта. Моя задача сконнектить этих двух индивидов так, чтобы у того, который информацию аплоадит, другой эту информацию забирал. По сути unixовые файл сокеты, это то, что нужно, то бишь мне не надо порт открывать(ибо как известно, их количество всё таки ограничено), и по сути можно совершать действия по мере поступления данных, то есть мне по сути не надо постоянно отпрашивать через скрипт, поступили ли новые данные или нет, за меня это сделает система, но загвоздка, даже платные хостинги не всегда любят сокетные соединения разрешать, вот поэтому и спрашивал, а что ещё возможно, может даже через обычные файлы, но с намёком на изменения в файле.
Вот было названо очень умное решение с шарингом памяти, очень заслуживающее внимания идея, только как там реализовать сокетное поведение, чтобы скрипт забирал данные именно по мере их поступления, а не постоянно отпрашивал в цикле, а не поступили ли новые данные? В общем такие вот дела. Да, я знаю, что это мои теории, предположения, как лучше сделать, чтобы не изобретать велосипед по новой, но судя по всему сознание отвечающих ограничено фразами о покупке платного хостинга, толковые мысли тяжело выудить.