Пишу прогу для фильтрации http-траффика. Идея: слушаем 127.0.0.1:<порт>, настраиваем браузер на использование прокси 127.0.0.1:<порт>. Все запросы, не анализируя, отправляем по назначению, ответы фильтруем как угодно. Пробую реализовать на синхронных сокетах. Код (Text): bind( sock, ( sockaddr* )&addr, sizeof( addr ) ); .. listen( sock, 100 ) while(1) { .. sock_in = accept( sock, ( sockaddr* )&inaddr, &sz ); //создаю поток, реализующий прозрачный http прокси } В потоке опять же цикл: не завершаю поток, пока сервер или браузер не закроют соединение. Вот. А проблема вот в чем: в определенный момент то-ли браузер перестает слать запросы, то-ли прокси перестает их принимать. Все как-бы висит, через некоторое время запросы могут возобновиться ( "ctrl+f5"-подобные действия в браузере ). Что здесь не так? Может не стоит держать соединения, а закрывать сокет зразу после завершения приема-передачи? Но тогда прокси будет медленнее работать, как мне кажется, да и http 1.1 протокол по умолчанию работает с постоянным соединением.
может стоит поставить таймаут на разрыв соединения (т.е сокет закрывать при том что нет ответа определенное время)
На сколько я вижу по своим логам, ответ есть. Перепроверю еще раз, но, кажется, проблема не в этом. Еще раз поясню. Есть цикл: 1. принять запрос от браузера (recv 1 ) 2. соединиться с сервером (connect) 3. переслать запрос серверу(send 1) 4. получить ответ от сервера(recv 2) 5. переслать ответ браузеру(send 2) После этого, если все connect/recv/send завершились без ошибок, возврат к п.1, не закрывая соединения. Т.е, на следующем цикле пропускаю соединение ( п.3 ). Так до тех пор пока нет ошибок приема/передачи. После этого закрываю сокеты и завершаю поток. Где здесь ошибка?
Поставлю вопрос по-другому: надо ли закрывать сокет после завершения каждого приема-передачи? Или браузер попробует использовать тот же сокет ( = соединение ) для следующего запроса? З.Ы. Протокол хттп знаю
А вот это, ты, наверное, тоже читал http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.2 http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.2.1