ruin, открывай => помощь => Internet => SendFile таким же макаром и через этот компонент, обрати внимание должен быть DataType=dtStream

Через некоторое время будут дополнительные компоненты, на базе текущих, умеющие отправлять файлы и строки без дополнительных плясок с бубном.

Редактировалось 7 раз(а), последний 2022-09-20 00:18:33

Спрошу тут

Пытаюсь осознать каким методом решить одну ошибку.
Схема цикличная и шлет каждые 300мск картинку по tcp, при хорошей связи нет необходимости что-то менять, все работает замечательно. Но стоит смоделировать плохую связь (wi-fi) как в подвисший tcp накидывает данные и происходит краш приложения.
Подскажите каким вариантом можно приостанавливать подачу в tcp при плохом соединении ?

проверяй сервер на доступность, потом отправляй Ping

Konst, не мог бы схематично подсказать цепочку ?

не совсем понимаю как проверять на доступность. в моем понимании только пинг и по его результату...

таким образом ?

code_34976.txt

тут наверное пинг не нужен, попробуй как то так:

code_34985.txt

Konst, еррор по ссылке
------------ Дoбавленo в 19.59:


картинку в потоке не получается отправить с конвертацией в стринг у этого компонента, как и в стандартном
у меня приходит не целая

как еще можно ее отсылать именно из потока?

пример прикреплен

Net2Com, см помощь-примеры-Internet-SendPicture.sha

Konst, в примере stream используется, а нужен стринг т.к этот компонента только в стринге идет

а стрим через конвертацию которая и рвет картинку как мне кажется

Netspirit, я на базе вашего компонента делаю web сервер, схема которая работает с клиентами(браузерами)находится в мультике.
При подключении клиента анализирую заголовки, смотрю что запрашивает, если страницу- выдаю страницу, если скрипт -то скрипт.

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

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

Не могли бы вы посоветовать как реализовать таймаут по которому соединение должно закрываться?

Помещать в мультик обычный таймер и запускать его по onClientConnect или есть другие варианты?


------------ Дoбавленo в 22.34:
Может использовать DefferedEvent?

1) С каждого клиента по приеме данных фиксировать дату последних данных
2) Поставить таймер, который периодически пробегает каждого клиента и сравнивает сохраненную дату с текущей
3) Если превышает заданный период - отключить


Не очень представляю, почему плохо. Думаю, схему нужно делать таким образом, чтобы она зависела от "действий" клиента, а не от "бездействий". Клиент ничего не делает - и сервер ничего не делает. Хотя чисто чтобы уменьшить нагрузку, таких клиентов стоит отключать (в текущем сервере неоптимальное использование потоков для прослушки данных от клиентов)

На сколько я понимаю TCP количество сокетов в системе тоже органиченно, процессором, оперативной памятью, процессором и буфером сетевой карты и настройками ОС.

Я когда-то тестировал web приложение в одной фирме, все работало как надо, но потом я решил открыть несколько тысяч сокетов - приложение вывалилось, потому что небыло ограничений на кол-во сокетов которое можно открыть с 1 ip адреса)) т.е. получилось некоторое подобие DDOS) хотя по факту сокеты должны были просто перестать открываться)

Это все лирика перейду к сути вопроса:

Допустим есть html страница на которой есть скрипт, css стиль, картинка.

При загрузке страницы браузер в несколько соединений спрашивает у сервера:

1) Саму страницу
2) Скрипт
3) css стиль
4) картинку
5) запрос который выполняет скрипт с страницы (postget не важно)

мини лог 1 соединения (загрузка 1 страницы):

CurClientID;запрос

38776654;page.html
58776655;script.js
38776655;style.css
58776656;image.jpg
58776655;(пост_запрос)


Судя по логу:
58776655;script.js
58776655;style.css
58776655;(пост_запрос)

клиент с ID 58776655 делает 3 запроса последовательно.

Вопросы:

1)
Для того чтобы что-то ответить клиенту (браузеру в моем случае) мне необходимо указать ClientID, перед отправкой данных...как выбрать "нужный" ClientID?
Запрашивается 2 файла и 1 ответ на запрос скрипта, все запросы с соединений с одинаковым ID...просто отвечать ему в том же порядке в котором он спрашивает?
т.е. отправляю клиенту c ID 58776655 сначала script.js, затем этому же ID style.css и т.д.?
А он (браузер) уже дальше сам разберется с полученными данными?
п.с. Проверял через doEnumClients - там тоже 3 одинаковых клиента числятся.

2) Как закрыть конкретное соединение в этом случае?
Например соединение в котором я отдал скрипт - не закрылось автоматически (браузеры тоже иногда Connection: close "мимо ушей" пропускают), как его закрывать...
если закрою по ID 58776655 - могу передачу других файловданных прервать..

3) Правильно ли схему следующим образом: На каждый запрос клиента - отдельный экземпляр схемы (в данный момент использую именно этот вариант)?

4) Можно ли настроить альтернативный сервер таким образом чтобы каждое подключение имело уникальный CurClientID?
Это бы очень упростило работу с WEB приложениями...при использовании TCP клиента стандартногоальтернативного - все CurClientID с 1 ip адреса разные как и положено...а при использовании в качестве клиента браузера попадаются одинаковые.
Я не берусь утверждать ни в коем случае, но может это баг?


п.с. причем данные которые поступают с одинаковым CurClientID не в одном соединении происходят последовательно...а в разных т.к. при запросе 1 страницы количество активных соединений = количеству запрашиваемых файлов.

Это уже есть и для этого введено понятие ClientID. CurClientID на момент всех событий всегда содержит ID клиента, от которого это событие произошло.
Здесь нет ничего необычного - браузер тоже экономит соединения. Кроме того, для протокола HTTP это штатная возможность, обеспечивается заголовком Connection: Keep-alive. Этот заголовок указывает серверу не разрывать соединение после ответа. Вероятно, это же должен делать клиент, если получит такой заголовок от сервера. Ну и разрыв соединения при Connection: close.

Ты неизбежно столкнешься с тем, что данные от клиента приходят порциями и в случае сервера, вперемешку от разных клиентов. Схему нужно строить таким образом, чтобы сохранять изолированное "состояние" каждого клиента. То-есть, когда данные приходят частями (для примера, 1 соединение), тебе по-любому нужно накапливать некоторое количество данных и после каждого фрагмента анализировать накопленные данные с целью получить полные заголовки запроса (накапливать до получения двух переводов строки). Если запрос GET, ты можешь начинать отправлять ответ. Если POST - смотришь Content-Length и продолжаешь накапливать данные, пока не получишь эту длину. Отправляешь ответ и снова переключаешься на ожидание двух переводов строки. Сделать это можно, например, динамическим мультиком:
- подключился клиент - добавили копию схемы в мультик, в схеме сохранили CurClientID для дальнейшего сопоставления
- отключился клиент - удалили схему
- получили любое другое событие - взяли CurClientID, в цикле перебрали все копии схемы в мультике, по нему нашли нужную и сделали её текущей, передали в нее событие на обработку.
- внутри каждой схемы в мультике и выполнять обработку привязанного соединения.

Редактировалось 7 раз(а), последний 2022-09-20 00:18:33