Берём обычный recv читаеет всё на ура как надо без сбоёв.
Берём Qt сокет и тут начинаються сбои. Лдано бы потсоянно, а то то нормлаьно то начинает лажу вычитывать...

У ктонить натыкался на грабли в сокете в Qt 4.3 при обработки больших объёмов данных ???

что за лажа-то хоть, опиши подробнее.

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

Эта... А ты какой режим используешь? Сокеты бывают блокируюшие и неблокирующие. У меня с сокетами никаких проблем всё работает отлично.

сокеты не блокируемы через сигналы..

привязываю к сигналу readyRead() свой обработчик там проверяю bytesAvailable() если там есть нужное мне число байт то считываю read() если там меньшее число ьбайт тогда выходу из обработчки и жду следующего сигнала.

Через н-ое время (всегдя по разному) вместо валидных данных начинаю считывать лажу.
Т.е предположим мне надо считать два байта, я получаю readyRead() захожу в свой обработчик проверяю bytesAvailable() на наличие этих двух байт, потом делаю read() проверяю что read() вернул мне правельно число прочитаных байт а вот содержание данных - фуфел.

хотя размер "пакета" данных не велик 60-200 байт но общий объём весьма ощутимый.

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

Что значит надо? А если протокол не подразумевает отправку размера данных или отправитель вообще не может в начале отправки определить сколько он будет отправлять?
В ручную бить трафик на блоки и добавлять информацию о размере? Для чего увеличивать объем передаваемых данных, если tcp стек это и так делает?
Достаточно корректно обрабатывать поступающие данные.

А отправка размера блока упрощает получение блока, но совершенно не обязательна.