Получение и обработка пакетов TCP/IP Опции

[Алексей1153]

Как Этого избежать?

1) ставить в данных метки (способов много, зависит от задачи)
2) использовать UDP ( тут система выдаёт при чтении ровно один пакет - хотя, могу ошибаться, но вроде так получалось. Если что, меня сейчас поправят )

[silver47]

Как Этого избежать?

1) ставить в данных метки (способов много, зависит от задачи)
2) использовать UDP ( тут система выдаёт при чтении ровно один пакет - хотя, могу ошибаться, но вроде так получалось. Если что, меня сейчас поправят )

Вот чего прочитал:

Передавать данные можно либо в виде текста, либо в виде блоков с данными (QTextStream и QDataStream). Для того чтобы определить можно ли читать данные из текстового потока, нужно вызвать QTcpSocket::canReadLine() а читать QTcpSocket::readLine(); Для блочных данных в начале передается размер блока, затем уже сам блок, и читаем только тогда, когда QTcpSocket::bytesAvailable() больше этого блока.

Вроде как-то так.

[ViGOur]

up

[Алексей1153]

silver47, абсолютно без разницы, текст это будет или бинарные данные (текст, вернее ASCII, - это тоже бинарные данные, только 7-й бит равен нулю у всех байтов)

Для блочных данных в начале передается размер блока, затем уже сам блок, и читаем только тогда, когда QTcpSocket::bytesAvailable() больше этого блока.

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

по хорошему, нужно ставить маркер начала (некий условный байт) - так мы точно знаем, что вот, например, тут может начаться сообщение, а всё до - мусор.
Затем идёт общий участок, где содержится указание длины и контрольная сумма (например, CRC16 с полиномом 0x1021). Ждём, когда придёт достаточное количество данных. По достижении - проверяем КС.
1) не совпала - значит ищем следующий байт-маркер.
2) совпала - значит с большой вероятностью получено отдельное сообщение

Кстати, не исключено, что в Qt уже есть готовое решение.

Сообщение отредактировал Алексей1153 - 15.1.2011, 20:16

[BRE]

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

А откуда может взяться мусор?
Для чего другой стороне посылать этот мусор?

[Алексей1153]

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

Ну, я не спорю, что когда всё идеально, про эту фигню можно не задумываться

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

[BRE]

TCP гарантирует целостность данных "из коробки". Какие помехи?

[Алексей1153]

BRE, гарантии нигде быть не может Отправитель может злоумышленно или из-за ошибки присылать левые пакеты. И всё - прощай нормальные сообщения на приёме. Это уже пройдено также на практике

[BRE]

BRE, гарантии нигде быть не может Отправитель может злоумышленно или из-за ошибки присылать левые пакеты. И всё - прощай нормальные сообщения на приёме. Это уже пройдено также на практике

Ну так этот же отправитель может умышленно или из-за ошибки устанавливать нужные маркеры. Не?

[Алексей1153]

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