Неблокирующий fsockopen

Потому что пхп использует системные вызовы для установки сокетов. И там ровно такой же механизм.

Да, есть - это её полная противоположность ☝

socket_set_blocking это псевдоним для функции socket_set_block - которая устанавливает блокировку сокетов, а socket_set_nonblock - запрещает их блокировку. Но работоспособность все равно зависит от системы.

neolord добавил 21.02.2009 в 20:04

уточняющий вопрос - что вы хотите получить? Какая цель запрета блокировки сокетов?

Разверните, плз, если не сложно. Такой же механизм, как и где?

Я про термины РНР говорил - есть способы установить сокет в неблокирующее состояние. Способы работают. Так почему не решается-то (в терминах РНР)?

Давайте без издевательств (понятно же, что в виду имелось) :)

Это полнофункциональные псевдонимы? Или есть недокументированные особенности?

Цель - не ждать, а продолжать выполнение скрипта. Это более-менее стандартная цель использования неблокирующих сокетов, не находите? :)

нет. цель - получение результата. если так дальше пойдет, вас начнут подозревать в сканировании портов, например.

так какой результат работы скрипта? вы могли просмотреть ряд очевидных технических схем.

Вы считаете, это корректный ответ на вопрос уважаемого neolord-а? Я так не считаю, поэтому ответил максимально конкретно.

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

А почему уклон подозрений в "криминал"? Неблокирующие сокеты только в неблаговидных целях используют? Или это "презумпция виновности" в действии? :)

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

Механизм тот же что и в ОС под которой запущен пхп. Раз есть способы, в чем ваш вопрос?

Ровно одно и то же.

Вот! И я о том же =) Но ТС упорно продолжает философствовать.

Т.е. вы хотите добиться возможности поддерживать сокет вне потока выполнения скрипта? Продолжать выполнять далее написанные команды? Т.е. вы хотите синхронизацию сокетов отключить? :) Или распаралеллить процесс? Или создать перманентный сокет?

neolord добавил 21.02.2009 в 21:03

В документации на пхп утверждается для этого есть единственная команда - socket_set_nonblock. И очень сомнительно что вы получите имено то что ожидаете (продолжение работы скрипта при получении данных из сокета). Вопрос закрыт. Поставьте другой вопрос если хотите услышать что-то конструктивное.

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

Ок, спасибо.

Я ответил на Ваш конкретный вопрос в контексте моих проблем с fsockopen

Я хочу сделать ровно то же самое, что описано в документе, ссылку на который я приводил в первом посте. У меня ровно такая же проблема - медленное установление первоначального соединения вплоть до истечения тайм-аута в fsockopen. Проблема решится, если перед вызовом функции fsockopen (или аналогичной) эту функцию получится перевести в неблокирующий режим.

Я в курсе того, что утверждается в документации.

Пока Вам сомнительно, я успешно получаю то, что ожидаю (продолжение работы скрипта при получении данных из сокета). Уже открытый и переведенный в неблокирующий режим сокет отлично обрабатывается скриптом. Как раз в этом я проблемы не вижу (и неоднократно выше об этом писал) т.к. все давно реализовано и замечательно работает. И вопрос еще не закрыт - отсутствие у Вас опыта решения моей проблемы не значит, что такого опыта нет в природе, согласитесь.

В приведенном документе вот что предлагается

if(fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1)
{
  /*
   * Не получилось...
   */
}

Если вы знакомы с документацией, вы должны были заметить строчку

Вы столько тут разглагольствуете, вы эту функцию пробовали? "не получилось"? Пора менять язык реализации.

neolord добавил 21.02.2009 в 22:15

Не поделитесь фрагментом кода? Хочется на это посмотреть, как это вы многопоточную интерпретацию замутили в пхп.

Не больше Вашего :) Если посмотреть внимательно, то все мои разглагольствования состоят из повторения моего вопроса.

Пробовал socket_set_blocking, которая "Ровно одно и то же". Не факт, что пробовал применительно ко всему арсеналу средств работы с сокетами. Не факт, что то, что пробовал было попробовано корректно. От того и создал тему в этом разделе, чтобы сократить временные издержки на эксперименты, если кто-то успешно решивший проблему сочтет возможным поделиться своим опытом.

neolord, Вы же, вроде, для себя мой вопрос закрыли. Или не до конца еще? :)

P.S. Вам самому не приходилось на практике решать сходные задачи? Про флаг я в курсе.

ОМГ, ТС, просто ОМГ.

socket_set_blocking это псевдоним функции socket_set_block! И она *устанавливает* блокировку сокетов

вам же требуется socket_set_nonblock, которая *запрещает* блокировку сокетов. Вы ЭТУ функцию пробовали? Если она возвращает фолс, значит при вашем методе работы с сокетом неблокирующийся сокет попросту невозможно поднять.

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

Кстати применительно именно к fsockopen все та же документация рекомендует использовать функцию stream_set_blocking

Для установки неблокирующегося режима нужно в mode поставить нолик.

Только вот эффективность этого метода в случае fsockopen мне представляется спорным, т.к. при вызове этой команды могут сразу начать передаваться данные (ответ сервера, доступность файла), причем в блокирующемся режиме, и только потом можно блокировку снять.

В омг уверены? На досуге посмотрите справку по socket_set_blocking. И обратите внимание на второй параметр. Буду рад, если дело дойдет до извинений с Вашей стороны.

Добавил позже: я смотрю, пост дополнили, пока я писал ответ :)