Вверх ↑
Этот топик читают: Гость
Ответов: 4628
Рейтинг: 749
#106: 2015-03-10 17:20:18 ЛС | профиль | цитата
Я не знаю. Может где-то есть ошибка в компонентах, а может в схеме при подсчете соединений. Возьми сервер и клиент из примера, подключи десяток штук к серверу - увидишь.
93.190.22.94 писал(а):
все эти запросы с одинаковым ID все равно в разных соединениях
Каким образом это выяснено? Как выглядит заголовок Connection, приходящий от браузера?
карма: 26

0
Ответов: 655
Рейтинг: 18
#107: 2015-03-11 00:04:05 ЛС | профиль | цитата
93.190.22.94
- это был я.

Собственно схема: http://forum.hiasm.com/forum_serv.php?q=56&id=3919

после запуска в браузере (желательно Chrome или любой другой на базе WebKit), набрать http:\127.0.0.1page.html

------------ Дoбавленo в 00.04:
п.с. схема может быть "кривовата" - набросал для теста.

-onClientConnect в случае с браузером срабатывает при каждом запросе от браузера, т.е. браузер спрашивает все в разных подключениях.
-в схеме отображается количество одинаковых CurClientID

карма: 0

0
Ответов: 4628
Рейтинг: 749
#108: 2015-03-11 12:27:57 ЛС | профиль | цитата
web server test.sha
Что здесь не так? Кроме того, что не учитывается фрагментация данных и не применяется параллельная обработка соединений.
Все запросы идут в разных соединениях. Если во все ответы поставить Keep-alive, то все запросы пройдут в одном соединении.

Твоя схема слишком большая, чтобы разбираться.
карма: 26

0
Ответов: 655
Рейтинг: 18
#109: 2015-03-11 17:33:00 ЛС | профиль | цитата
Netspirit,я не прошу вас разбираться в моей схеме, я прошу ее запустить и выполнить загрузить страницу в браузере http:\127.0.0.1page.html.


Ваша схема проста может поэтому не наблюдается эффекта одинаковых CurClientID, на моей странице CSS,картинка,4 скрипта, 2 из них - шлют запрос серверу.

Вы сами постом выше спросили:
Каким образом это выяснено?


Я выложил схему, я настаиваю на том чтобы вы посмотрели схему , не надо ее править или еще что-то, просто посмотрите как разработчик компонента почему в некоторых разных запросах появляется CurClientID.


карма: 0

0
Ответов: 4628
Рейтинг: 749
#110: 2015-03-11 17:46:19 ЛС | профиль | цитата
Так я посмотрел: при запросе появляется одно соединение, браузер зависает - схема ничего не отдаёт (на точку doSend ничего не приходит)
карма: 26

0
Ответов: 655
Рейтинг: 18
#111: 2015-03-11 18:28:23 ЛС | профиль | цитата
У меня работает, щас поправлю..
------------ Дoбавленo в 18.28:
http://forum.hiasm.com/forum_serv.php?q=56&id=3920

Вот еще урезал схему, бывает вылетает, не знаю почему (возможно из-за одинаковых CurClientID), попробуйте пожалуйста.
В браузере нужно прописать http:\127.0.0.1page.html.
карма: 0

0
Ответов: 4628
Рейтинг: 749
#112: 2015-03-11 19:12:22 ЛС | профиль | цитата
Я тебе говорю, что протокол HTTP предполагает возможность множественных запросов в одном соединении. Браузеры сами могут решать, как поступать. Ты ж не думаешь, что если я на странице выведу 100 <img>, то браузер откроет 100 соединений? Что будет с сетью, и какой сервер это позволит?
карма: 26

0
файлы: 1dfsdfdsfdfdf.jpg [71.3KB] [1124]
Ответов: 655
Рейтинг: 18
#113: 2015-03-11 20:24:27 ЛС | профиль | цитата
Netspirit, в моей схеме видно же что лог создается с точки onReceive а не on Connect так же хочу отметить что количество onReceive=onConnect, что означает что каждый запрос данныхфайла идет в разных подключениях, а не в одном!

При работе по HTTP 1.1 все соединения считаются постоянными, если не обозначено иное.[1] При этом постоянные соединения не используют сообщения keepalive, а просто позволяют передачу множественных запросов в одном и том же соединении. Тем не менее, время ожидания по умолчанию в httpd для Apache 2.0[2] составляет всего 15 секунд, а для Apache 2.2 лишь 5 секунд.[3] Преимуществом короткого таймаута является возможность быстрее передать клиенту множественным соединением несколько компонентов веб-страницы, а не более долгим методом инициации нескольких серверных процессов или потоков.[4


https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%BD%D0%BE%D0%B5_HTTP-%D1%81%D0%BE%D0%B5%D0%B4%D0%B8%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5


У нас не Apache, ни чего не обозначено, просто открываютсязакрываются сокеты.

Скриншот на котором у вас 3 синих кубика (одинаковые CurClientID) - проверьте в Chrome еще раз, и вы увидите что эти запросы не в 1 соединении идут а в разных.

НО компонент все равно считает что CurClientID у них одинаковый.

HTTP это спецификация протокола, а не реализация его работы...его работа реализуется браузером который, при открытии страницы смотрит DOM и кол-во запрашиваемых файлов, если файлов нужно скачать 20, то он будет их качать по несколько штук в разных соединениях!. по 5-6 файлов, затем еще 5-6 файлов, партиями, но в разных соединениях.

Я не сомневаюсь в ваших знаниях TCP и HTTP, я просто пытаюсь понять...как в разных соединениях могут получаться 2-3 одинаковых CurClientID.
Мне кажется компонент считает подключения браузера не верно..или я совсем не знаю как работает HTTP тогда.

п.с. Откуда берется CurClientID как высчитывается? Открывал ваши pas...там везде "Conn" указан, откуда он берется не понял..


п.п.с. браузер скачал script1.js или script2.js, результат выполнения скрипта - отправка строки request_1 или requets_2.
Обратите внимание что CurClientID при загрузке скрипта и отправки данных из него - разные.

Мне удалось воспроизвести ситуацию когда сервер производит 1 раз событие onConnect (допустим CurClientID будет 123), а затем несколько последовательных onReceive (все CurClientID 123) - это когда я шлю из браузера серверу POST запрос на 50 000 символов, браузер режет его и пропихивает в 1 соединении, это и получается "постоянное соединение" которое организует браузер. В этой ситуации все правильно, 1 клиент, большой объем данных от него, все данные приходят по очереди и у всех onReceive одинаковый CurClientID.

Во всех остальных случаях количество onConnect=количеству onReceive и некоторые CurClientID одинаковые, это ошибка, так не должно быть...если блин onConnect происходит значит что сервер считает это подключение как новое!!! Отчего же он ему тогда дает CurClientID который уже был выдан??
карма: 0

0
Ответов: 4628
Рейтинг: 749
#114: 2015-03-11 21:23:25 ЛС | профиль | цитата
Gunnman писал(а):
Откуда берется CurClientID как высчитывается?

Отсюда:


#pas
function TTCPServer._ExecuteAccept (T: TThread): Integer;
var
Connection: TClientConnection;
ClientSocket: TSocket;
Addr: TSockAddr;
AddrLen: Integer;
FDRead: TSocketSet;
TimeVal: TTimeVal;
begin

TimeVal.tv_sec := 2; // Таймаут ожидания соединения - 2 сек
TimeVal.tv_usec := 0;

while (not T.Stopped) and (FSocket <> 0) do
begin

FDRead.Count := 1;
FDRead.Socket := FSocket;

// Ожидаем входящее подключение (поток приостанавливается на таймаут)

case select(0, PFDSet(@FDRead), nil, nil, @TimeVal) of
SOCKET_ERROR:
begin
if not T.Stopped then StopListen;
Break;
end;
0: Continue; // Таймаут
end;

// Получено соединение - обрабатываем

FillChar(Addr, SizeOf(TSockAddr), #0);
AddrLen := SizeOf(TSockAddr);

ClientSocket := accept(FSocket, @Addr, @AddrLen);

if ClientSocket = INVALID_SOCKET then // Возникает в случае сбоя сети или закрытого FSocket
begin
if not T.Stopped then StopListen;
Break;
end;

// Если за время таймаута было получено подключение, а сервер остановлен -
// закрываем подключение (оно автора программы, вероятно, уже не интересует)
if T.Stopped then
begin
shutdown(ClientSocket, SD_BOTH);
closesocket(ClientSocket);
Break;
end;


Connection := TClientConnection.Create;
ConnectionAdd(Connection);
with Connection do
begin
OnDisconnect := _OnDisconnect;
if Assigned(Self.OnErrorSend) then OnErrorSend := _OnErrorSend;
if Assigned(Self.OnProgress) then OnProgress := _OnProgress;
if Assigned(Self.OnReceive) then OnReceive := _OnReceive;
if Assigned(Self.OnSend) then OnSend := _OnSend;

ReceiveDelay := FRecvDelay;
RecvDelaySize := FRecvDelaySz;
AsyncEvents := Self.AsyncEvents;
SetSocket(ClientSocket, Integer(Addr.sin_addr), ntohs(Addr.sin_port));
SendTimeout := Self.SendTimeout;
end;

if not T.Stopped then
begin
if Assigned(OnClientConnect) then
begin
if AsyncEvents <> ASYNC_EVENTS_ALL then
T.Synchronize(_SyncClientConnect, Connection)
else
_SyncClientConnect(nil, Connection);
end;

//В OnClientConnect соединение может быть закрыто, поэтому проверяем на существование
if ConnectionExists(Connection) then Connection.StartReceiving;
end;
end;
end;
А именно, ID есть указатель на созданный здесь объект:
Connection := TClientConnection.Create;

Выходит, что в Delphi если создать некий объект, затем уничтожить его, а потом опять создать такой же, он вполне может получить адрес предыдущего. Избежать этого никак нельзя, да и не требуется. Важно то, что в любой момент времени в списке коннектов сервера всегда будут уникальные ID. Просто нужно помнить такую особенность. В схеме все равно нужно выполнять обработку onConnect/onDisconnect. Не могу представить ситуации, где важно, чтобы ID были уникальные. Они предназначены только для сопоставления событий/методов с указанным соединением. Нет соединения, нет с чем и сопоставлять.

А вот возможная ситуация, когда событие приходит из соединения 123, и пока обрабатывается, соединение закрывается и приходит новое соединение с тем же номером 123 и уже ему направляется ответ - это некорректная работа схемы: по отключению первого соединения 123, любая, предназначенная ему работа должна быть отменена. И для следующего 123 начата заново.
карма: 26

0
файлы: 1hjghjs.jpg [32.3KB] [559]
Ответов: 655
Рейтинг: 18
#115: 2015-03-11 21:34:07 ЛС | профиль | цитата
Что если с CulClientID добавить integer:=random(1000)? (в Delphi оч слабо разбираюсь).

Таким образом в списке коннектов не будет одинаковых (для 1000 коннектов точно)
------------ Дoбавленo в 21.34:
Gunnman писал(а):
Важно то, что в любой момент времени в списке коннектов сервера всегда будут уникальные ID. Просто нужно помнить такую особенность.


Имеешь ввиду что допустим есть CurClientID 123, он отработал и у следующего коннекта может появится такой же?
карма: 0

0
Ответов: 4628
Рейтинг: 749
#116: 2015-03-11 21:38:23 ЛС | профиль | цитата
Gunnman писал(а):
у следующего коннекта может появится такой же?
Выходит, что так. Новый объект создается в ближайшем подходящем участке памяти, который может освободиться после предыдущего объекта.

Можно проще - сделать целочисленный круговой счетчик, возможно, с проверкой на наличие вновь сгенерированного номера в списке существующих соединений. Но это неэффективно, нужно будет вести двусвязный список "номеров" и физических соединений.
Более правильно тщательней обрабатывать дисконнект клиентов - все равно нужно освобождать выделенные ранее ресурсы и т.д. Например, если ты начал отправку файла, а в этот момент соединение было разорвано? Нужно закрыть открытый ранее файл, другие какие-то действия.
карма: 26

0
Ответов: 655
Рейтинг: 18
#117: 2015-03-11 22:41:08 ЛС | профиль | цитата
Netspirit, да, я проверил, запросил 6 несуществующих файлов, у всех был разный CurClientID. Значит будем знать что delphi так работает.
карма: 0

0
Ответов: 4628
Рейтинг: 749
#118: 2015-03-13 18:25:49 ЛС | профиль | цитата
.....
карма: 26

0
Ответов: 655
Рейтинг: 18
#119: 2015-03-13 22:37:48 ЛС | профиль | цитата
я что-то не то сказал?
карма: 0

0
Ответов: 4628
Рейтинг: 749
#120: 2015-03-15 10:33:00 ЛС | профиль | цитата
[offtop]Форум заглючил: при редактировании поста он вставился как новый. Удалите кто-нибудь последние 3 поста[/offtop]
карма: 26

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)