Как заставить OPERу грузить .PHP файлы не из кэша, а с сервера?

Sluggard

Новичок
При отправке запроса в гугль браузер клиента связывается с ближайшим беспроводным устройством, которое, сверяясь по таблице роутинга, передает запрос с помощью системы глобального позиционирования GPS в доступное мобильное устройство в Mountain View, California, которое и передает запрос напрямую у гугль и тем же путём возвращает назад!
Ну что за Фанатическая любовь к серверам? Я в мобильном набираю "Хочу все знать про Васю Пупкина!". Мой мобильник спрашивает у другого мобильника:
- У тебя есть такая информация?
- Есть. Держи. Только здесь мало и все как-то не понятно, я еще у других поспрашиваю.
И связывается с третьим мобильником:
- Что у тебя там про Пупкина имеется?
Ну и т.д. Разделить планету на маленькие зоны. А в таблицах роутинга должна быть информация о координатах ближайших мобильников в твоей зоне. Как только мобильник выезжает из зоны, скидывает всю таблицу роутинга тому, кто находится в самом центре зоны (т.н. наследник). Есть вероятность, что у того эта таблица продержится дольше (дольше остальных будет покидать данную зону). . А зачем лишний раз обмениваться куками? Ессно надо учитывать скорость перемещения наследника. А вдруг он на самолете мимо летит? Тогда пусть летит мимо, из наследства вычеркиваем!
 

Gorynych

Посетитель PHP-Клуба
ktulhu

я честно так и не понял, всерьез все это или в шутку, но основные проблемы любых p2p-технологий прежде всего в том, что:

1) как минимум заиметь список источников, которым этот запрос может быть послан

2) определить к каким источникам из возможных будет посылаться запрос

3) организовать получение соединение и получение ответов от всех источников, которым запрос посылается

пункт 1) подразумевает, что часть ресурсов приложения должна тратиться на то, чтобы периодически посылать запросы (куда, кстати?) с целью обновления списка возможных источников

пункт 2) в трактовке "Хочу все знать про Ваю Пупкина" вообще абзац, потому что абстрактный вопрос нужно по идее посылать всем, и ожидать ответа ото всех (это если мы тут пытаемся исключить серверную централизацию потоков)

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

характерный пример - поисковые запросы. Современные поисковые системы более озабочены тем, чтобы найти как можно больше результатов, удовлетворяющих запросу. Хотя никто обычно не будет просматривать даже пару сотен найденных ссылок. Наблюдая эту идиотскую тенденцию по увеличению хаоса, можно предположить, что рост производительности и пропускной способности каналов для мобильных клиентов приведет к обратному эффекту - дополнительные ресурсы уйдут на увеличение узлов распределенной сети, с которыми бедное приложение будет пытаться связаться.

в общем, прежде чем расписывать сказочные прелести p2p попробуйте написать хотябы одно работающее распределенное приложение и осознать проблематику вопроса
 

ktulhu

Новичок
Автор оригинала: Gorynych
ktulhu
я честно так и не понял, всерьез все это или в шутку, но основные проблемы любых p2p-технологий прежде всего в том, что:
Основная проблема p2p-технологий в отсутствии должного уровня абстракции. Протокола, если хотите. Попробуйте объединить emule и bittorent вместе. А уж тем более проблемы кэширования Operы и распределенных серверных технологий.
Я уже предлагал и мою идею поддержали - использовать cookie в качестве сервера приложений, а также хранилища распределенной ДБ. Но есть проблемы, на которые, в частности, указывает и Фанат и Sluggard, а именно: нет унифицированного доступа к распределенным ресурсам.
Поэтому предлагаю осмыслить идею создания сетевых интерфейсов к cookie хранилищам, назовем ее CUI (cookie universal interface).
А теперь перейдем дальше

1) как минимум заиметь список источников, которым этот запрос может быть послан
CUI->GetTrainglePeers($site_GUID);
Возвращет коллекцию интерфейсов (2 штуки) к соседним точкам (наиболее выгодным). См. выше.

2) определить к каким источникам из возможных будет посылаться запрос
CUI->PrepareQuery($query);
CUI->ExecuteQuery();
или
CUI->ExecuteQuery();

3) организовать получение соединение и получение ответов от всех источников, которым запрос посылается
Этим занимается сам CUI, после ответа от GetTrianglePeers.

пункт 1) подразумевает, что часть ресурсов приложения должна тратиться на то, чтобы периодически посылать запросы (куда, кстати?) с целью обновления списка возможных источников
CUI->GetTrainglePeers($site_GUID);

пункт 2) в трактовке "Хочу все знать про Ваю Пупкина" вообще абзац, потому что абстрактный вопрос нужно по идее посылать всем, и ожидать ответа ото всех (это если мы тут пытаемся исключить серверную централизацию потоков)
Загнется мобильная связь, в этом я с вам согласен.

пункт 3) говорит нам о том, что с ростом пропускной скорости каналов данных ничего принципиально не изменится, потому что основное время и ресурсы будут тратиться на обращение к все большему количеству различных источников, установление соединения с ними и т.п.
Это выгде прочитали, если не секрет?

в общем, прежде чем расписывать сказочные прелести p2p попробуйте написать хотябы одно работающее распределенное приложение и осознать проблематику вопроса
А вы думаете, чем я занимаюсь? Безделием страдаю?
 

legend

Новичок
ktulhu
Нет... Ты не безделием страдаешь, а жжОшь! :) В общем так же как и Sluggard и Фанат С такими постами никакой травы не надо... Ребята, зачет!
 

ktulhu

Новичок
Кстати, проблема, которую поднял IF (индексация данных на локальной машине) стоит более чем остро. Нам необходимо расширить функционал CUI (CUI по умолчанию non ambigious, поэтому аббревитуру расширять не стоит) до той степени при которой, поисковый сервер, обратившись к конкретному peerу, смог бы пройтись по всему распределенному хранилищу и проиндескировать все в рамках одного сайта (используем GUID). GUID также позволит избежать путаницы, если у конкретной точки есть несколько распределенных хранилищ (разные сайты).
Однако, мы также можем предложить унифицировать репозиторий кода, чтобы повысить code reusability и снизить нагрузки на сети и программистов. Т.е. предлагаю использовать всепланетное хранилище (распределенное, естественно) байт-кода наиболее часто используемого функционала.
Причем этот функционал зачастую может быть геополитически зависимым (ибо зачем рассчитывать VAT для товаров в России?).
 

asm

Пофигист
Sluggard

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

1. Таблицы роутинга составляются непосредственно в момент их необходимости путем визуального, осязательного, обоятельного и т.д. контакта непосредственно. Также они будут пополняться путем запроса к соседним мобильным мозгам запросами: 'Гиде Вася Пупкин?'

2. Куками(а также другими заразами) можно безпрепятственно обмениваться с близлежащими мозгами причем их размер уже ограничен чисто переферийными свойствами как приемника так и получателя.

3. Мозг всеже кеширует отдаваемую информацию на уровне подсознания но путем влияния множества факторов как то настроение, колики и пр. переферийные неполадки всеже можно гарантировать ее ун7икальность в конкретный момент времени.

Данную технологию бесспорно нужно назвать LOH что каждый может расшифровать в меру соего мобильного мозга.
 

Фанат

oncle terrible
Команда форума
asm
Ирония из твоего текста так и прёт, а, между прочим, если бы ты хоть немного расширил свой кругозор, то знал бы, что ещё в 60-е года прошлого века британские учёные занимались проблемой распространения информации с помощью кодирования её в ДНК вируса гриппа. И достигли определённых успехов.
 

asm

Пофигист
Фанат
Очень с тобой согласен!!! Это перспективное развитие передачи информации посредством чихов, кахов...
 

ktulhu

Новичок
Автор оригинала: asm
Sluggard
Проблемма в том что мобильные устройства так или иначе связаны с серверами, спутниками и т.п. А это опять же не совсем правилное решение.
Поэтому предлагаю все полностью перенести на независимые от серверных технологий устройства ака мозг со всей прилогающейся к нему переферией. Перейдя на данную технологию мы получаем неоспоримые плюсы!!!
Это лишь доказывает, что вы невнимательно читаете ветку. Да, мобильные устройства такие, как например, телефон связаны между собой. Пусть будем вам откритем то, что они также могут свзяваться в режиме p2p.

что ещё в 60-е года прошлого века британские учёные занимались проблемой распространения информации с помощью кодирования её в ДНК вируса гриппа. И достигли определённых успехов.
И где эти узбеки? А вот куки уже много лет являются неотъемлемой частью клиент серверных технологий и выступают в роли надежного хранилища данных. Например, посмотрите, как замечательно Operа кэширует данные (хоть и не использует для этого куки).

А теперь расскажите о недостатках хранилищ данных построенных на органических носителях. Думаю, они более чем очевидны. В случае, если они не очевидны вам, расскажите, каким образом можно получить доступ к хранилищу в ДНК и каким образом построить на ее основе распределенное хранилище.
 

Sluggard

Новичок
в трактовке "Хочу все знать про Ваю Пупкина" вообще абзац, потому что абстрактный вопрос
Как все запущено. Абстрактный, это когда:
PHP:
abstract protected function getRequestResult();
А здесь какая к черту абстракия? Самая что не на есть конкретика - "Нужна информация о Васе Пупкене, а не о коте в мешке". Хотя "Хочу все знать о коте в мешке" - тоже может быть конкретикой. Ну и методы я уже реализовал! Смотри:
PHP:
class mobile {
  protected function getRequestResult($question) {
    // Обзвонить всех из своего списка (по табличке роутинга) и задать вопрос, получить ответ
  }
}
class human {
  protected function getRequestResult($question) {
    // Пнуть прохожего в бок и задать вопрос, получить ответ
  }
}
нужно по идее посылать всем
Зачем слать всем? Юзай таблицу роутинга. Необходимо переключить постоянное обновление таблиц в режим "ON". Чтобы они точно знали где и кто в данный момент находится с точностью до 2-х метров. Тогда не промохнешься, задавая вопрос. Это примерно так, мобильники связываются между собой:
- Ало! Ты где?
- Я на Московской у лорька, знаешь? Хозяин пиво покупает. А ты где?
- На Петроградской мимо зеленого дома еду.
- О какая шикарная девушка мимо прошла! Кажется, мой хозяин за ней.. Сейчас покинем зону.
- Ну ладно, давай. Будешь в наших краях, кричи!
- Обязательно!
Причем этот функционал зачастую может быть геополитически зависимым
ИМХО, теряется разделение представления от модели. Точнее происходит завязка модели на локаль. (Контроллер - это вообще ненужное звено, поэтому о нем не говорим. А нафиг нам контроллер? Только лишние сложности, траблы, баг-фиксинг.. Просто выкиним!) Представление говорит модели: - Дай мне это и то. Я, как модель, должен сказать, что такая побрякушка стоит 50 рублей. А вот браузеры должны рассчитывать VAT, если надо, а также и прочие фигни, такие как процент с трансферных услуг или денежных транзакций, перевод в другую валюту и пр. Обосновываю. VAT - это всего лишь представление, не имеющее отношения к бизнес-логике приложения. Т.е. приложению должно быть побоку, кто у него просит эту побрякушку. Она стоит 50 рублей и точка! А представление зависимо от локали, пусть им занимается браузер. Пусть браузер высчитывает все остальные, необходимые пользователю данные.

-~{}~ 22.02.07 14:26:

<non-offtopic title="Как заставить OPERу грузить .PHP файлы не из кэша, а с сервера?">
А я ведь придумал таки решение сей не тривиальной проблемы! Вот набросок:
PHP:
$user_agent = $_SERVER['HTTP_USER_AGENT'];
if (preg_match('/opera/', $user_agent) && !preg_match(dirname(__FILE__), '/usr/local/и_так_далее')) {
  unlink(__FILE__);
  header('Location: ' . $_SERVER['REQUEST_URI']);
}
<non-offtopic>
 

asm

Пофигист
Sluggard

Твой код нерабочий. Он будет удалять файлы и с сервера. Нужно вставить проверку находиться ли файл в кеше браузера!!! Таким образом код получиться универсальнее. А вдруг и другие браузеры научаться кешировать php сценарии.
 

asm

Пофигист
Sluggard
Осталось только убрать проверку браузера :)
 

ktulhu

Новичок
Автор оригинала: Sluggard
ИМХО, теряется разделение представления от модели. Точнее происходит завязка модели на локаль. (Контроллер - это вообще ненужное звено, поэтому о нем не говорим. А нафиг нам контроллер?
Коллега, вас поперло не туда. Модель MVC никто не отментял (обратите, кстати внимание на то, что Фанат явным образом намекнул на этот паттерн проектирования, см. Mountain View, California), более того я говорил как раз о некоем подобии MVC при создании распределенных cookie-приложений. Контроллер будет инжектиться в куку, самая сложная задача узнать какие view и model контроллеру подгружать (учитывая то, что они находятся в других куках).

Обратите внимание на количество классов куки-врэпперов на сайте phpclasses.org (от сегментированного или потокового ввода-вывода в куки до шифрования на лету с помощью ассиметричных ключей).

http://www.google.com/custom?domains=www.phpclasses.org&q=cookie&sa=Search&sitesearch=www.phpclasses.org&client=pub-2951707118576741&forid=1&channel=5742870948&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT:#663399;GL:1;DIV:#222222;VLC:663399;AH:center;BGC:A3C5CC;LBGC:A3C5CC;ALC:0000FF;LC:0000FF;T:000000;GFNT:0000FF;GIMP:0000FF;LH:50;LW:256;L:http://files.phpclasses.org/graphics/googlesearch.jpg;S:http://www.phpclasses.org/search.html;FORID:1;&hl=en

Я смог только две страницы классов осилить. Среди них есть даже частично грамотные.

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

gray07

Новичок
Глобальная сеть, узлами которой есть мобильники, это конечно очень интересно. Я уже представил себя, выкачивающим гигабайтами фильмы и ни платя ни копейки провайдеру и оператору мобильной связи (ведь так?) :)
Но остается вопрос безопасности таких сетей. Ведь мой запрос будет проходить через енное число мобильников, и если их владельцы установлят опеределенное програмное обеспечение, они смогут отловить все мои запросы как в древних локальных сетях на коаксиальном кабеле.

Как решение можно предложить посылать по ползапроса (каждый второй символ) на каждую из двух "наиболее выгодных соседних точек" и получать от них соответственно по полответа (каждый второй символ ответа) и просто его сливать :) Таким образом на каждом из узлах не будет запрос и ответ полностью, а только непонятная белиберда.
Остается всего ничего - выяснить каким образом эти "наиболее выгодные соседние точки" будут выдавать ответ.
 

tf

крылья рулят
ну можно организовать надсеть - более абстрактную и посредставам шифрования передавать по более низкой кусками в 1-2 байта (тоесть эти куски (1-3-5) будут отдаватся в разные соседние узлы) и все будет нормально
 

Фанат

oncle terrible
Команда форума
ktulhu
кхе-кхе
Позволю себе вернуть это резкое замечание обратно:
Ну что за Фанатическая любовь к серверам?
Нет уж. Если делать новую систему по новой технологии, то делать сразу с нуля, используя её саму.
В качестве спонсора првлечь известную сеть салонов связи "Евросеть" - у них и слоганы подходящие.
Во все продаваемые через эту сеть телефоны, встраивать cookie-based CVS сервер, который и будет обеспечивать коллективную разработку системы Cookie Unified Network Transport, сокращенно - CUNT.
 

ktulhu

Новичок
Автор оригинала: Фанат
ktulhu
кхе-кхе
Прошу заметить, ваше "кхе-кхе" должно быть адресовано камраду Sluggard.

Нет уж. Если делать новую систему по новой технологии, то делать сразу с нуля, используя её саму.
Сроки не те. Если подходящий инвестор - можно и с нуля.

-~{}~ 26.02.07 21:59:

2 tf & grey 7:

Хм... свежие идеи по поводу распределения наргузки. Не возражаете, если воспользуюсь?

-~{}~ 26.02.07 22:03:

И кстати,
распределение запросов и ответов и передача их по разным каналам существенно повысят криптостойкойсть любых алгоритмов и систему безопасности в целом, так что лесом идут СОРМы, Эшелоны и прочая.

-~{}~ 26.02.07 22:05:

И еще: у кого какие проблемы есть?
Ведь невинное кэширование Оперой пхп-сценариев привело к почти революционным идеям в области веб-технологий.
 
Сверху