Что же вы шлете в этом самом первом write()?
Запрос GET?
Ок, вы пишите - ответ получаете
Какой именно - те что отвечает сервер, 200 ОК?
Данные какие шлет?
Если пришло все, что вы хотели - то ясное дело что вы на сервер ничего не посылаете
А если пришел ответ - то надо что-то сразу слать
Кстати какой интервал вы ставите в TCP_KEEPALIVE?
Наверно с логикой запросов-ответов (те верхним протоколом) у вас что-то не так  


Ну а ошибка то какая? что лежит в errno?

Все правильно - послали один запрос, получили один ответ - все. Шлите другой запрос, сам по себе http сервер ничего лить не будет, keep alive тут ни при чем   

В первом запросе я шлю 
sprintf(request, "GET / HTTP/1.1\r\nHost: %s\r\n\r\n", hostname); 
ответ:



вот так я выставляю TCP_KEEPALIVE, 
if(setsockopt(sd, SOL_SOCKET, SO_KEEPALIVE, (char*)&len, sizeof(len)) == -1){
              perror("tcp_listen: setsockopt(SO_KEEPALIVE) 1"); 
            return 0;
}
время коннекта я понимаю должно в линуксе sysctl выставлятся(хотя можно через структуру tcp_kpalive, но в сигвине у меня такого нет), но даже так думаю время соединения должно быть больше секунды так что я бы успел получить хотя бы два ответа.




А что может быть не так ?


в errno: 113 (connect abort)

А вот если я шлю    sprintf(request, "GET / HTTP/1.1\r\nHost: %s\r\nKeep-Alive: 300\r\nConnection: keep-alive\r\nReferer: http://%s/\r\n\r\n", hostname, hostname);
то ответ получаю 

А в Errno: 
errno: 119 (connection in progress)
errno: 119 (connection in progress)
errno: 113 (connect aborted)
..............

Добавлено @ 16:42

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

Вот испытал на лунуксе, думал переводить неблокирующий режим в асинхронный если errno == EINPROGRESS, но получил еще более странный результат.
при посыле вот этого получил 



как понимать Cannot process request!  server does not support the action requested by the browser, может что-то в апаче включить ? 


Это сообщение отредактировал(а) fray - 17.12.2007, 18:24

настройки системы
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75

Что это за хитрый файл?
Content-Location: index.html.en - который лежит в каталоге Апачей?
Поэтому Апачи отвечают что

Апач наверно незнаком с расширением .en?
После чего, так как ошибка явная, он соединение наверно и закрывает- и вам приходится все по новой делать
В общем при нормальной конфигурации Апачей и клиента все должно работать и без всяких TCP_Keepalive  тд
Надо точно формулировать запросы

я заменил index.html.en на index.html, результат остался прежним. 


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


Это сообщение отредактировал(а) fray - 19.12.2007, 00:35

Опять пишет что метод не поддерживается в первом ответе?
Можете опять распечаточку респонса привести?

Насколько мне известно, по закрытии соединения другой стороной в select будет постоянно возникать read event, а read() или  recv() будут возвращать 0.

вот таким запросом запрашиваю главную страницу на localhost'e:
sprintf(request, "GET / HTTP/1.1\r\nHost: %s\r\nKeep-Alive: 300\r\nUser-Agent: (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070208 Firefox/2.0.0.6
\r\nAccept: text/plan;q=0.8,image/png,*/*;q=0.5\r\nConnection: keep-alive\r\nReferer: http://%s/\r\n\r\n", hostname, hostname); 
вот ответ:
это соответсвено index.html



а дальше я cделал так что послал запрос если не получил на него ответ, но новый запрос не шлет даже если poll'er  говорить что можно писать, 

send req: 1 // шлю первый запрос 

HTTP/1.1 200 OK
Date: Tue, 18 Dec 2007 23:20:26 GMT
Server: Apache/2.2.6 (Mandriva Linux/PREFORK-8mdv2008.0)
Last-Modified: Fri, 07 Sep 2007 20:47:11 GMT
ETag: "ef786-2c-be3491c0"
Accept-Ranges: bytes
Content-Length: 44
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

<html><body><h1>It works!</h1></body></html>

send req: 2 // шлю второй запрос
ответа не получаю 
тут прога висит в ожидании ответа на второй запрос через тот же коннкт.
[user@localhost 2]$ netstat -t
tcp        0      0 localhost:46809      localhost:http       CLOSE_WAIT

и соединение весит в таком состояние бесконечно долго. Сам сервак (как бы это сказать) до конца соединение не закрывает.

Теперь вернемся к первой цитате.
Вы используете select() на клиенте в цикле?
Если да, то тогда все понятно.
Его в цикле использовать можно, но только специальным образом - иначе все сбрасывается и больше на сетевые события он не реагирует - те после первого запроса все замирает

Да, но только не select()'том, а его собратом poll()'ом, но думаю тут нет большой разницы.


Объясните плизз, а то я не очень понял почему.


Это сообщение отредактировал(а) fray - 19.12.2007, 13:58

Не могу сказать про poll() - хотя вполне вероятно

Те если перед этим вы делали все FD_SET - те заносили в нужный набор - и по этому признаку не сработало - а сработало по другому - то все наборы после select() обнуляются и для исполнения select() в цикле надо делать все FD_ SET заново

это все конечно круто , но я понял что у меня не работает даже так 


Программа получает только ответ от первого запроса. А от второго ничего.

хотя эти отлично работаетают когда я руками их копирую.


Это сообщение отредактировал(а) fray - 21.12.2007, 17:09

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

означает: "читать пока не произойдёт disconnect"

onsql прав, и ему большой плюс за это  
Этот фрагмент:        

предполагает продолжение операции чтения до тех пор, пока не выскочит ошибка
 (-1 ) или не прийдет признак FIN n=0 - а это точно, что соединение закрыто!!!
Почему бы просто не написать 

и слать следующий запрос по еще открытому сокету!!!!

Это сообщение отредактировал(а) Олег2005 - 21.12.2007, 18:03