Смесь бульдога с носорогом: моя версия :))

← →
savva © (2002-07-19 11:14) [0]

Короче дела такие... подробности того, как я пытаюсь открыть сокет..
const // В заголовке необходимы некоторые данные HTTP_Data = "Content-Type: application/x-www-form-urlencoded"#10+ "User-Agent: Chat Client By Savva (savva@nm.ru)"#10+ "Host: savva.ru"#10+ "Connection: Keep-Alive: on"#10; ....
Соединение открываю так:
function TForm1.DoConnect(user,msg : string): boolean; begin Content:= msg + #10; // Вычисляем длину содержимого Content:= "Content-Length: "+IntToStr(Length(Content))+#10+#10+Content; if chUseProxy.Checked then begin {-- Начало прокси ---} ClientSocket1.Host := edProxyServer.Text;; ClientSocket1.Port := StrToIntDef( edProxyPort.text,3128); HTTP_POST := " http://"+edWebServer.Text+":"+edWebPort.text+" "+ user+""#10; {--- Конец прокси ---} end else begin {--- Начало соединения напрямую --- } ClientSocket1.Host := edWebServer.Text; ClientSocket1.Port := StrToIntDef( edWebPort.text,3000); HTTP_POST := user+#10; {--- Конец соединения напрямую ---} end; // Соединяем заголовок HTTP_Post := HTTP_Post + HTTP_Data; // открываем соединение ClientSocket1.Active:=true; mess_str:=HTTP_POST+Content; result:=true; end; ... procedure TForm1.ClientSocket1Write(Sender: TObject; Socket: TCustomWinSocket); begin // Постим данные при коннекте Socket.SendText(mess_str); mess_str:=""; end;
то есть фактически после этого мы имеем открытый транспортный канал, но дальнейшие телодвижения типа Socket.SendText("что нибудь"); не приводят ни к какому результату. Причем со стороны сервера такие вещи проходят - клиент получает сообщения и прекрасно их может читать :)

тут мне напрашивается вопрос - а не надо ли перед посылкой сообщения от клиента серверу к тексту припысать какую либо еще информацию? Может прокси сервер прикрывает соединение (хотя это наврядли - сообщение-то от сервера приходят) !?!

← →
Digitman © (2002-07-19 11:27) [1]

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

← →
savva © (2002-07-19 11:41) [2]

ага

← →
savva © (2002-07-19 11:42) [3]

ведь событие OnConnect возникает при присоединении с прокси серверу..

← →
Digitman © (2002-07-19 11:57) [4]

А OnWrite(), по-твоему, чем отличается от OnConnect() ?

OnWrite() следует сразу за OnConnect() и говорит лишь о доступности буфера гнезда к записи в него данных, которые ты собираешься передавать.

Собственно, криминала здесь нет никакого, можно и OnWrite() пользоваться как фактом коннекта, но оно может возникать и неоднократно. Как минимум, это ты не учитываешь, imho. Т.е. в какой-то момент времени в очередном событии OnWrite() ты пошлешь серверу вовсе не то, что он ожидает в соответствии с протоколом http , и сервер просто "заткнется", не понимая тебя. Что, похоже, у тебя и происходит ...

Не исключена ситуация с потенциальным нарушением протокола инф.обмена.

Убедись, что OnWrite() вызывается неоднократно.

← →
Digitman © (2002-07-19 12:07) [5]

Вот фрагмент хэлпа с описанием к сетевому событию FD_READ :

The FD_WRITE event is handled slightly differently. An FD_WRITE message is posted when a socket is first connected with connect/WSAConnect (after FD_CONNECT, if also registered) or accepted with accept/WSAAccept, and then after a send operation fails with WSAEWOULDBLOCK and buffer space becomes available. Therefore, an application can assume that sends are possible starting from the first FD_WRITE message and lasting until a send returns WSAEWOULDBLOCK. After such a failure the application will be notified that sends are again possible with an FD_WRITE message.

← →
savva © (2002-07-19 12:09) [6]

при использовании SendText - точка останова сработала 1 раз - при коннекте..
а когда возникает событие OnWrite, при каких условиях?

← →
Digitman © (2002-07-19 12:09) [7]

Пардон, ошибочка :
... фрагмент хэлпа с описанием к сетевому событию FD_WRITE

← →
savva © (2002-07-19 12:10) [8]

ясно..

← →
savva © (2002-07-19 12:21) [9]

причем посылка заголовку прокси серверу в момент коннекта (OnConneсted) не меняет картины...

← →
Digitman © (2002-07-19 12:21) [10]

клиент-то у тебя ctNonBlocking или ctBlocking ? Это важно с т.з. логики возбуждения событий

← →
savva © (2002-07-19 12:24) [11]

ctNonBlocking

← →
Digitman © (2002-07-19 12:30) [12]

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

Убедиться каким-либо образом в факте события FD_READ на серверной стороне ты в состоянии ?

← →
Digitman © (2002-07-19 12:33) [13]

т.е. текст в mess_str на момент передачи - некорректен, видимо.

← →
Wonder © (2002-07-19 12:34) [14]

Извиняюсь за вмешательство :), а прокси-то какой? HTTP?

← →
savva © (2002-07-19 12:35) [15]

>сервер получает клиентский исх.поток
речь идет я так понял про прокси сервер?

что значит в состоянии?:)) осталось выбрать "образ"...
При возникновении события OnRead на сервере строка перво-наперво сохраняется в лог-файл... (Пока речь идет тока строках..) Если можно вклинится раньше такого способа - то я не знаю как.

← →
savva © (2002-07-19 12:39) [16]

>Wonder © (19.07.02 12:34)
ага..
любому вмешательству я тока рад :))
>Digitman © (19.07.02 12:33)
то есть мы приходим к выводу что перед отсылкой необходимо к тексту сообщения приплюсоввывать что-то.. такой вариант тоже не проходит - прибавляю тоже самое что и при коннекте..

← →
Digitman © (2002-07-19 12:41) [17]

Пока речь идет о прокси : он первый в цепочке передачи получает кл.поток, анализирует, фильтрует и перенаправляет ...

Упс ... <Wonder> верную ведь мысль подал : с прокси самим все в порядке ? http держит он ?

← →
savva © (2002-07-19 12:44) [18]

именно http он и держит (поддерживает..) через него IE работает...
прокси - WinRoute..(если это важно :))

← →
Wonder © (2002-07-19 12:45) [19]

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

← →
Digitman © (2002-07-19 12:46) [20]

"приплюсоввывать что-то" или наоборот убрать лишнее - здесь уже я тебе вряд ли что-то подскажу ... вступает в силу ПИО с прокси-сервером, "держащим" http...

разумеется, если прокси "споткнулся" на твоем заголовке запроса, никакой речи о трансляции его целевому узлу и речи быть не может ...

← →
Digitman © (2002-07-19 12:49) [21]

← →
savva © (2002-07-19 12:50) [22]

>Wonder © (19.07.02 12:45)
я тоже так думал..
но тут тогда появляется не понятка почему функция
function TForm1.Send_Text( msg : string): boolean; begin Content:= msg + #10; // Вычисляем длину содержимого Content:= "Content-Length: "+IntToStr(Length(Content))+#10+#10+Content; if chUseProxy.Checked then begin {-- Начало прокси ---} ClientSocket1.Host := edProxyServer.Text;; ClientSocket1.Port := StrToIntDef( edProxyPort.text,3128); HTTP_POST := " http://"+edWebServer.Text+":"+edWebPort.text+" "+ {user name}nickname+""#10; {--- Конец прокси ---} end else begin {--- Начало соединения напрямую --- } ClientSocket1.Host := edWebServer.Text; ClientSocket1.Port := StrToIntDef( edWebPort.text,3000); {--- Конец соединения напрямую ---} end; // Соединяем заголовок HTTP_POST :=HTTP_Post+#$D#$A+ msg+#10; HTTP_Post := HTTP_Post + HTTP_Data; mess_str:=HTTP_POST+Content; sckt.SendText(mess_str); result:=true; end; не имеет желаемого результата...

← →
Digitman © (2002-07-19 12:53) [23]

Так, ну а "Журнал http" в WinRoute что показывает на эту тему ? Или это сложно - поиметь такую инфу ?

← →
savva © (2002-07-19 12:56) [24]

>Digitman © (19.07.02 12:53)
ща

← →
Wonder © (2002-07-19 12:59) [25]

Как я делал в таких случаях дабы не обременять себя вычитыванием RFC и составлением правильных http-пакетов :)))

- Берем снифер
- Браузером отправляем данные через форму по какому-либо адресу (например, постинг сюда)
- Смотрим http-пакет
- Отправляем твоей программой
- Смотрим http-пакет
- Сравниваем оба пакета на предмет различий

← →
savva © (2002-07-19 13:02) [26]

>Wonder © (19.07.02 12:59)
подход верен.. но почему один и тот же пакет не проходит 2 раза..

← →
Wonder © (2002-07-19 13:04) [27]

Непонял. Ты ж говоришь, что от клиента к серверу вообще ничего не идет. Какие два раза?

← →
Digitman © (2002-07-19 13:08) [28]

Получается, что первое сообщение имеет корректный формат (и Web-сервер, обработав, вернул тебе результат) , а последующие - некорректный.

Ты хочешь сказать, что "напрямую" (без прокси) обмен идет успешно ?

Так, стоп. Ты уже двоих запутал) ...

О факте установления транспортного канала говорит как минимум событие OnConnect(), никакие логические данные, передаваемые в SendText() в OnWrite() или еще где-то к транспорту как таковому отношения не имеют - он либо есть либо его нет ...

Вот теперь скажи - есть ли реакция Web-сервера на самый 1-й SendText() ?

первый раз проходит - при коннекте DoConnect функция а второй : Send_Text - их содержание практически идентично.. при коннекте сервер получает:
/ savva Content-Type: application/x-www-form-urlencoded User-Agent: Chat Client By Savva (savva@nm.ru) Host: savva.ru Content-Length: 27 Connection: close
а далше тихо как в гробу..

лог:
[19/Jul/2002 13:10:02] Packet filter: ACL 2:0 Intel(R) PRO Adapter: permit packet out id=36386 : TCP 192.168.0.XX:3627 -> 192.168.0.XX:3128 [19/Jul/2002 13:10:02] Packet filter: ACL 2:0 Intel(R) PRO Adapter: permit packet out id=36388 : TCP 192.168.0.XX:3627 -> 192.168.0.XX:3128 [19/Jul/2002 13:10:02] Packet filter: ACL 2:0 Intel(R) PRO Adapter: permit packet out id=36389 : TCP 192.168.0.XX:3627 -> 192.168.0.XX:3128 [19/Jul/2002 13:10:02] Packet filter: ACL 2:0 Intel(R) PRO Adapter: permit packet out id=36391 : TCP 192.168.0.XX:3627 -> 192.168.0.XX:3128
дальнейшие посылы SendText не вызывают у прокси никакх изменений..

то что я запутал - это я понял :)))
поясняю ситуацию :))
есть сервер слушает 1 порт.. к примеру 3000. он в интернет лезет без прокси..
есть клиент, выходящий через прокси..

все остальное я уже говорил :))) по порядку :))))

Например, в HTTP_Data вот это вот:
"Connection: Keep-Alive: on"#10;
ты откуда взял?

"есть сервер слушает 1 порт"
один порт ? или первый ? ну почему так трудно написать недвусмысленно-то ?

Какой сервер ? Web-сервер ? Зачем ему куда-то "лезть" ? Клиент в Интернет "лезет" к Web-серверу через цепочку прокси (твой WinRoute да еще, может быть - прокси провайдера) ...

Вот это поясни ...

и вот это еще :

Connection: close

как это сочетается с твоим

Connection: Keep-Alive: on

?

>Wonder © (19.07.02 13:31)
это совет нашего веб-мастера-админа :)) если честно, то я с трудом представляю зачем это, но если ему верить, то так прокси должен оставлять соединение :)))

>Digitman © (19.07.02 13:35)
прошу прощения.
один порт. конечно сервер никуда не лезет :)) просто я сказал это в такой форме чтоб было понятно что ему ничего не мешает видеть прокси сервер клиента напрямую... (как бы опять не запутать..)

>Digitman © (19.07.02 13:38)
а вот это уже выше моих знаний...
"Connection: close" - это приходит моему серверу от прокси

"Connection: Keep-Alive: on" - это посылает коиент прокси серверу..

в поддержку того, что соединение все таки существует - прокси сервер закрывает через 10 минут (время простоя) соединение...
вполне возвможно что это тока соединение с прокси сервером..

Блин, ничего не пойму)

Что есть "мой сервер" ? Мы говорим об отладке HttpChat-клиента или некоего (не твоего и не в твоей ЛВС) Web-сервера, на котором размещен скрипт твоего же чат-движка?

вот где собака порылась:)))
мы говорим о Chat-клиенте на протоколе HTTP и сервере не моей сети (но это признак не обязателен, в принципе к программе серверу будет доступ и из локальной сети). Исполнение сервера - не скрипт. Win32 приложение...

Грубо говоря - чат из примеров Делфи по сокетам, тока расширенный до возможности работать через HTTP proxy

Смесь бульдога с носорогом: моя версия :)) Найти похожие ветки