Повторное использование ресурса сокета

roundrobbin

Новичок
Здравствуйте!
столкнулся со следующей проблемой:
если из открытого дескриптора ресурса сокета прочесть результат ответа сервера, то последующие попытки использования этого сокета, без повторного открытия - невозможно, так как устанавливается флаг eof, о чём свидетельствует вызов stream_get_meta_data для дескриптора ресурса этого сокета, например:
PHP:
$fs = fsockopen($host, $port, $errno, $errstr, $timeout);
.....
$headers[] = "GET / HTTP/1.1";
$headers[] = "Host: $host:$port";
$request = join("\r\n", $headers)."\r\n\r\n"; 

fwrite($fs, $request, strlen($request));

$out = '';
while ($resp = fread($fs, 1023)) {
	$out .= $resp;
}

print_r(stream_get_meta_data($fs)); # флаг eof, как и следовало ожидать, установлен в TRUE

и следующие попытки писать/читать в сокет, не приводят к успеху.

Подскажите пожалуйста, как без повторного вызова fsockopen, осуществлять общение с этим открытым сокетом?

Спасибо!
 
следующие попытки писать/читать в сокет, не приводят к успеху.
ну а к какому именно "неуспеху" они приводят? а сервер проинформирован, что у вас еще может возникнуть желание что-нибудь ему написать?
какие заголовки отправляются и какие возвращаются ? особенно со словом connection в названии
 
ну а к какому именно "неуспеху" они приводят?
собственно, после того, как я повторно пишу в ранее открытый хэндл сокета (и из которого уже осуществлялось чтение посредством fread с последующей установкой флага eof = TRUE), при попытки чтения из него возвращается просто пустая строка.
 
fwrite возвращает (правильно возвращает) кол-во записанных в сокет байт, однако, вызов fread возвращает FALSE, так как установлен флаг eof для этого дескриптора сокета, и собственно поэтому, возникает проблема сабжа
 
сорри, не верно вас понял, если вы про HTTP-заголовки, то после первого чтения из сокета, мы получаем Connection: close, но ведь HTTP - это Уровень приложения в OSI, и к сокетам он как бы мало отношения имеет
возможно, это реализация самой ф-ции fsockopen следит за заголовками именно ХТТП ответов, и если это так, то тогда попробую использовать более нискоуровневые, типа socket_create
 
так если оно пишет, но fread возвращает false и Connection: close, то что собстно ты хочешь? я этого понять не могу... там HTTP/2.0 вышел, который поддерживает чат с сервером? или что ты хочешь добится, отправляя данные после получения результата своего 1го запроса?
 
ок, я хочу один раз открыв сокет (fsockopen) иметь возможность несколько раз писать и читать в него отправляя разные запросы без доп. вызовов fsockopen
Это нельзя, так как fread возвращает false после первого прочтения данных и сокета... в этом собственно и заключается вопрос: вожно ли как-то "сбросить" этот флаг eof = true, для этого сокета, что бы последующие вызовы fwrite/fread работали с тем же самым экземпляром дескриптора ресурса ранее открытого секета
 
так с какой стати и руководствуясь какими спецификациями, HTTP сервер обязан получать и отдавать данные нескольких запросов в одном соединении если он вам английским языком сообщает, что Connection : close.. ?

Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling takes place using the Connection header field (section 14.10). Once a close has been signaled, the client MUST NOT send any more requests on that connection.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.2
 
кстати, сейчас вот появилась такая идея, но проверить не могу, а именно:
если в fsockopen открывать соединение не напрямую к хосту, а скажем к проксе (например SOCKS5), и затем писать/читать уже через дескриптор сокета прокси, повторно не устанавливая с ней соединение... получится ли такое либо же использование сокса то же не поможет и флаг eof будет установлен в любом случае, после получения Connection: close в заголовке ответа ?
 
roundrobbin
флаг EOF стравится когда вы доходите до конца буфера,никто не следит за данными проходящими через сокет
сокс это просто "труба" через которую передаются ваши данные,она не контролирует что и куда идёт,так что нет,не поможет
P.S.
писать собственный механизм работы с HTTP - глупо,для этого есть curl
 
Сверху