Я, вроде, описал подробно. Допускаю, что криво. Можете уточняющие вопросы задать?
Можно попросить пояснить? Почему не решается? В терминах РНР вроде как решается (за исключением самого начала, да и то, я не уверен, что это не мой косяк).
У нее есть какие-нить принципиальные отличия от socket_set_blocking? За исключением того, что они из разных семейств.
Смысл есть.
У Вас есть решение?
Нет, конечно :) Неблокирующие сокеты немного для другого...
Хм... мне казалось, я корректно описал проблему, с которой столкнулся. Давайте, попробую объяснить с другого конца.
Проблема не в том, что я не могу организовать работу с fsockopen, stream_socket_client или cURL (с этим, как раз, все в порядке), а в том, что не получается у меня работать с сокетом в неблокирующем режиме с самого начала соединения. Эта же проблема хорошо описана по ссылке, которую я привел в первом посте. Т.е. мне надо, чтобы к моменту отправки первого бита в сторону удаленной машины (при установлении соединения) сокет уже находился в неблокирующем режиме.
Если же действовать стандартными методами, описанными в мануалах, то установить неблокирующий режим для сокета можно только после установления соединения с удаленной машиной. В подавляющем числе случаев этого достаточно. Я столкнулся с исключением - в отдельных случаях сам процесс установления соединения (когда сокет еще в блокирующем режиме) затягивается. Мне надо уйти от этого затягивания установив неблокирующий режим для функции fsockopen. Или для любой другой аналогичной, хоть для stream_socket_client, хоть для чего-то в cURL или в низкоуровневом интерфейсе сокетов.
KosoyRoman, спасибо за готовность помочь. Не могли бы Вы пояснить, в каком участке Вашего кода содержится ключ к решению моей проблемы? Стыдно признаться, но я увидел лишь стандартное использование библиотеки cURL, не решающее моей проблемы, как мне кажется.
Для чего нужно перевести fsockopen в неблокирующий режим? Чтобы дать возможность скрипту не останавливаться на время тайм-аута этой функции. Т.е. стандартная цель использования неблокирующего режима.
MiRaj, надо полагать, формулировки обдуманные?
Тогда есть вопросы...
Размерность вИЦ не подскажите?
А почему именно сайта, а не, например, кластера? И почему изначально предлагаете считать, что трастранк влияет на видимость сайта?
Добавил:
Пардон, сразу не заметил этой фразы. Весьма спорное утверждение насчет исключительности роли внешних ссылок.
А то, что он (optimist.ru) не в индексе, Вас не смущает?
Т.е. у Вас получилось сайт optimist.ru увидеть выше bdbd.ru?
Вы, как бы, намеренно описались? :)
Стремление повысить точность, надо полагать. При одновременной проверке 1000 доноров точность по каждому донору получается выше, чем при одновременной проверке 100 доноров.
wolf, по ходу, ты и ТС про разные вещи говорите. В разных плоскостях. Ты - сам знаешь, про что. А он - про влияние проставленной ссылки на траст реципиента. Так, как ты меряешь, у тебя и не будет нулей. А он измеряет прирост траста. Ссылка может быть мощной в твоих терминах, но не давать прироста траста в его. Почувствуй разницу, она принципиальна.
Другое дело - чистота его эксперимента, смелость выводов и всё остальное. Например, в его "теории окна" не хватает механизма вытягивания этого самого окна в сторону обособленной скученности.
Эх, знать бы devzev по его открытым работам, чтобы оценить жесткость его внутренних стандартов ;)
