Вверх ↑
Этот топик читают: Гость
Ответов: 893
Рейтинг: 18
#1: 2008-05-10 12:54:50 ЛС | профиль | цитата
Это уже не впервой я замечаю баг с отпаданием TCP_Client от сервера без видимых причин при пересылке больших масивов данных , как с этим боротся не знаю !!!

Ситуация значит такая , я написал прокси сервер через него например пытаюсь загрузить файл размер до 1 го мегобайта , качает TCP_Client клиент (принимает ) 150 - 300 килобайт а затем разрывает соединение
Вопрос почему так происходит ?

Схема прилагается

code_2220.txt


карма: 0
Время верстки: %cr_time% Текущее время: %time%
0
файлы: 1code_2220.txt [4.2KB] [219]
Администрация
Ответов: 15295
Рейтинг: 1519
#2: 2008-05-11 13:42:46 ЛС | профиль | цитата
тестирование в локальной сети происходит?
карма: 27
0
Ответов: 893
Рейтинг: 18
#3: 2008-05-13 08:05:34 ЛС | профиль | цитата
Dilma писал(а):
тестирование в локальной сети происходит?

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

[size=-2]------ Добавлено в 08:05
Исправленная схема ввиду багов с косыми я подправил схему

code_2223.txt
карма: 0
Время верстки: %cr_time% Текущее время: %time%
0
файлы: 1code_2223.txt [3.2KB] [176]
Ответов: 3851
Рейтинг: 159
#4: 2008-05-13 10:12:47 ЛС | профиль | цитата
Есть хороший способ сражаться с проблемами, известный ещё древним (и нам со школы) - разделяй и властвуй.. Предлагаю определиться с заявленной "профнепригодностью" клиента. Я в локалке пробовал больше 3 МБ - не обрывается (то, что частями передаётся - это другой вопрос)..
вот сервер: code_9032.txt
вот клеент: code_9033.txtприём текста сделан неправильно, но для наших целей это не важно (я думаю), просто некогда мне сейчас..
карма: 0
начавший
0
файлы: 2code_9032.txt [645B] [191], code_9033.txt [1KB] [179]
Ответов: 893
Рейтинг: 18
#5: 2008-05-13 15:01:36 ЛС | профиль | цитата
Андрей., а ты пробовал етим клиентом с http сервера скачать чонить пусть даже локально ?
Естли ты разбираешся в этом хоть немного лучше меня , пожалуйста очень прошу помоги правильно зделать данную схему http://hiasm.com/xf/topic.php?t=20846&start=0
карма: 0
Время верстки: %cr_time% Текущее время: %time%
0
Ответов: 3851
Рейтинг: 159
#6: 2008-05-13 16:39:58 ЛС | профиль | цитата
Byuik, я в этом плохо разбираюсь. Но есть штатный пример HiAsmElementsDelphiExampleInternethttp_server.sha там показано как сервер отсылает данные (не только текст) в текстовом виде. У меня IE открывал с этого сервера картинку ~1,4 МБ (локально ессно)..
карма: 0
начавший
0
Ответов: 206
Рейтинг: 19
#7: 2008-05-13 16:45:22 ЛС | профиль | цитата
это вроде Byuik делал
карма: 0
Время : %time% Текущее время: %time%
1
Голосовали:Byuik
Ответов: 3851
Рейтинг: 159
#8: 2008-05-13 16:49:41 ЛС | профиль | цитата
Ghost_Russia писал(а):
это вроде Byuik делал
если про http_server.sha, то по моему автор элемента TCP_ServerEx (возможно в кооперации)
карма: 0
начавший
0
Ответов: 893
Рейтинг: 18
#9: 2008-05-13 18:14:56 ЛС | профиль | цитата
Ghost_Russia писал(а):
это вроде Byuik делал

штатный пример делал не я

Андрей. писал(а):
Byuik, я в этом плохо разбираюсь. Но есть штатный пример HiAsmElementsDelphiExampleInternethttp_server.sha там показано как сервер отсылает данные (не только текст) в текстовом виде. У меня IE открывал с этого сервера картинку ~1,4 МБ (локально ессно)..


Вот тут какраз и конфуз что сервер работает а клиент нет
карма: 0
Время верстки: %cr_time% Текущее время: %time%
0
Ответов: 893
Рейтинг: 18
#10: 2008-05-15 17:49:54 ЛС | профиль | цитата
Последние данные о глючности элемента находятся здесь http://hiasm.com/xf/topic.php?t=20846&start=10

[size=-2]------ Добавлено в 17:49
Вопрос : Почему я должен доказывать людям которые ничего не хотят слышать , что их компонент в среде Delphi глючит ?
карма: 0
Время верстки: %cr_time% Текущее время: %time%
2
Голосовали:Ghost_Russia, tsdima
Гость
Ответов: 17029
Рейтинг: 0
#11: 2008-05-15 18:52:29 правка | ЛС | профиль | цитата


Редактировалось 1 раз(а), последний 2017-03-04 14:28:52
карма: 0

0
Ответов: 3851
Рейтинг: 159
#12: 2008-05-15 18:53:27 ЛС | профиль | цитата
Гость это я был..
карма: 0
начавший
0
Администрация
Ответов: 15295
Рейтинг: 1519
#13: 2008-05-20 13:48:26 ЛС | профиль | цитата
в пакете QT компоненты TCP сопровождаются гарантией качества от фирмы разработчика - есть повод попробовать себя в построение кросплатформенных схем.
карма: 27
1
Голосовали:Konst
Ответов: 3851
Рейтинг: 159
#14: 2008-05-20 14:52:34 ЛС | профиль | цитата
пакет QT платный надо полагать (для коммерческого использования)?
карма: 0
начавший
0
Ответов: 2125
Рейтинг: 159
#15: 2008-05-21 21:46:10 ЛС | профиль | цитата
Byuik писал(а):
Почему я должен доказывать людям которые ничего не хотят слышать , что их компонент в среде Delphi глючит ?

Давай определимся: глючит у тебя, возможно ещё у кого-то.
А вот я у себя глюков не замечал. Вопрос: как я могу поймать глюк, которого у меня нет?

------------ Дoбавленo:

Byuik, мне сначала было лень анализировать, как работает твоя схема, но ты вынудил меня сделать это своими заявлениями.

Первое, что бросается в глаза: необоснованное наличие целых трёх компонентов Thread, пользоваться ими надо аккуратно, и всегда иметь ввиду, что возможен одновременный доступ со стороны нескольких из них.
В данном случае было не особо важно, т.к. обе цепочки, в которых присутствует Thread запускались последними, после onRead сокета. Однако исключать то, что следующий onRead придёт раньше, чем отработает Thread, тоже нельзя.

Второе, насчёт onRead: в схеме данные сначала записываются в StrList, а потом уже оттуда передаются на отправку, причём всегда. С текстовыми данными так ещё можно поступить, а вот с бинарными (картинки) - не советую. Нет никакой гарантии, что StrList не уберёт пару символов перевода строки или не обрежет "строки" после символа (если так можно выразиться о бинарных данных, разделённых символами
).

Третье, опять про onRead: было бы наивным полагать, что весь ответ от браузера ты получишь в одном onRead. Это ты учёл - молодец. Но как? Что произойдёт, когда придёт второй onRead?
1. снова анализ заголовка. Зачем? А если всё таки встретится GET или POST - произведёшь модификацию данных? Но ладно, это маловероятно.
2. соединение активно, опять запускаем Thread (вероятно, чтобы освободить от пересылки данных основной Thread), однако предыдущая посылка данных могла ещё не завершиться (multithread блин) - опять наплевали на это.
3. что у нас там после хаба? Опять doOpen TCP_Connection! Не поленился, заглянул в код компонента:
procedure THITCP_Client._work_doOpen;
var p:word;
h:string;
begin
if not Assigned(Sock) then Attach(TSocket.Create); // сокет уже есть - ладно, проглотили
P := ReadInteger(_Data,_data_Port,_prop_Port);
H := ReadString(_Data,_data_IP,_prop_IP);
Sock.StartClient(p,h); // но тут мы сделаем ему снова StartClient. Что произойдёт?
end;
А произойдет следующее:

procedure TSocket.StartClient;
var addr:sockaddr_in;
begin
CreateWindow;
FSocket := socket(PF_INET, SOCK_STREAM, IPPROTO_IP); // открываем ещё один сокет! про старый забыли начисто, хотя именно туда надо было посылать данные.
addr.sin_family := AF_INET;
addr.sin_port := htons(Port);
addr.sin_addr.S_addr := inet_addr(PChar(Host));
if connect(FSocket,addr,sizeof(addr)) <> 0 then // опять соединяемся с сервером
begin
closesocket(FSocket);
FSocket := 0;
end
else
begin
BeginRead; // ещё один новый Thread, теперь уже для чтения из сокета. Мало нам существующих Thread? Между прочим, предыдущий так и продолжает читать из первого сокета.
if Assigned(onConnect) then
onConnect(self);
end;
end;

Вобщем, как это всё работает - непонятно. Основная проблема - пункт 3. Учитывая, что браузер иногда использует то-же самое соединение для посылки следующего запроса.
Или всё-таки пункт 2? Незаконченная Thread-ом пересылка обрывается новым запросом...
------------ Дoбавленo:

Ну что, Byuik, допёк ты меня
Действительно есть баг в TCP.pas. Ставлю тебе плюс, за настойчивость.
В очередной раз убедился, что на локальном компьютере и в локальной сети - две большие разницы.
Дома смоделировать ситуацию, как ты понимаешь, не получалось.
Все работающие с сокетами - качаем обновление http://hiasm.googlecode.com/svn/elements/delphi/code/TCP.pas

Как всегда, ошибка была там, где её меньше всего искали - на видном месте.
карма: 1

1
Голосовали:Konst
Сообщение
...
Прикрепленные файлы
(файлы не залиты)