Dima TДля общего развития: допустим ты передал строку
при передаче строка была разбита на пакеты

TCP гарантирует что эти 3 пакета придут именно в той последовательности, как ты отправил, т.е. 2-й не придет раньше 1-го, но НЕ гарантирует что ты получишь все 3 вместе, т.е. может прийти например 1-й, а затем 2,3 вместе.

Это один из вариантов. В реальности пакет побольше ~1.5 кб, и может быть наоборот ситуация, когда в одном пакете несколько строк или начало в одном пакете, а конец в другом.

И как мне это собрать в правильную последовательность строк?

Dima TSergey_rb1.У меня на сервере работают 100 терминалов и я не могу менять логику его работы
Что мешает работать по аналогии с терминалом?

Терминальная прога написана на Лазарусе и там, аналог функции recv, возвращает сообщение целиком, а не кусками.

MasterZivФееричный топик.
Почему-то в последнее время я видел несколько похожих проблем вокруг себя.
Да и сам (как ни странно) решаю сейчас аналогичную.

Что же это, нашествие телепузиков в индустрию?

Это всего лишь одна, криво написанная, функция recv.

MasterZivРешил вернуться к истокам, так сказать, проблемы...

Sergey_rbПроблема в том, что, при завершении приема данных, функция recv переходит в режим ожидания следующего пакета.


Это нормальное поведение этой фукнции. Так и должно быть.


Sergey_rbПример кода:




Цикл выбирает все данные из буфера и останавливается в режиме ожидания на строке



Это тоже нормально, и цикл нормальный.

Sergey_rbКакие есть варианты выхода из цикла?


На самом деле из этого цикла вообще выходить не надо .
Как у тебя написано, так правильно, и так и должно всё работать.
Ты выбираешь данные, обрабатываешь их когда надо, потом выбираешь следующие.
(т.е. в цикл надо ещё где-то добавить обработку этих данных).

Когда клиент завершает соединение, он закроет сокет, и твой recv вернёт что-то меньше 0-ля и твой цикл завершится.
После этого ты должен закрыть серверный сокет , возможно, что-то ещё освободить и завершить с серверной стороны,
и завершить серверный поток (либо сокет убрать из числа обрабатываемых).

А что же ты хочешь в твоём вопросе -- не понятно вообще.

Я на каждой странице пишу одну фразу - соединение, после передачи данных, не закрывается!

Dimitry SibiryakovSergey_rbЯ на каждой странице пишу одну фразу - соединение, после передачи данных, не закрывается!

И тебе каждый раз на это отвечают, что это совершенно пофиг. Тебе не нужно выходить из цикла.


В этом случае recv останавливается, ждет следующей порции данных от сервера и программа зависает.

После обработки последнего пакета, recv ничего не возвращает, а ждет новый пакет.

Dima TSergey_rbпропущено...


Терминальная прога написана на Лазарусе и там, аналог функции recv, возвращает сообщение целиком, а не кусками.
Если терминальная прога работает, значит можно тоже самое повторить в любой другой проге. Чудес не бывает. recv() получает все тоже самое что и терминальная прога, проблема тут только в том что ты не можешь корректно запустить recv().

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

Я прекрасно знаю, в каком формате передается информация с сервера, т.к. я сам его написал.
А передается она в виде строк, разделенными символами переноса строк 13 и 10.

Dima TSergey_rbТерминальная прога написана на Лазарусе и там, аналог функции recv, возвращает сообщение целиком, а не кусками.
Как функция в лазарусе называется? Если исходники той проги есть, то покажи как прием прописан, быстрее помогут на С++ переписать.

Это я тоже уже писал на предыдущей странице

авторВ Indy все просто -
На сервере
WriteStrings


Предает набор строк

На клиенте
ReadStrings


Получает набор строк и запихивает в StringList.

И никаких циклов, потерь данных и прочего мусора.

Возможно, единственный выход - это, как было предложено, искать два переноса строк подряд, но это уже совсем лоховская тема.

Dima TSergey_rbпропущено...

Я так подозреваю что все циклы и прочий "мусор" спрятаны внутри этих функций. Подобные вещи не стандартизированы, поэтому за пределами твоего Indy это не работает и надо разбираться как оно реально устроено в Indy.

Сделай WriteStrings() двух строк "123" и "abc", прими recv() все что придет, запиши в файл и выложи сюда этот файл.

Для небольших сообщений, менее 2 Кб все прекрасно работает, т.к. это сообщения помещаются в один пакет.
Проблема начинается при приеме больших сообщений, т.к. протокол разбивает их на пакеты.

Dimitry SibiryakovSergey_rbЭто я тоже уже писал на предыдущей странице

Писать-то ты горазд, но вот заглянуть в исходники WriteStrings() и прочитать их - тебе уже
не по плечу.

Sergey_rbВозможно, единственный выход - это, как было предложено, искать два
переноса строк подряд
С какого перепою ты решил, что твой сервер следует соглашениям HTTP?


1. Смотрел, там сначала берется количество строк, затем они считываются.
2. Я писал, что использую протокол HTTP?

Dimitry SibiryakovSergey_rbПроблема начинается при приеме больших сообщений, т.к. протокол разбивает их на пакеты.

Да, именно так работает TCP и именно это тебе твердят с самого начала. Но до тебя никак не
доходит. Видимо, твой мозг работает по UDP.


Они работают в режиме открытия и закрытия сокета.
В моем сервере, сокет, после отправки/принятия сообщения, не рвет соединение.