Проблема с TCP/IP

Не путайте всех терминологией. В данном случае ваш сервер опрашивает клиента, т.е. вы все перепутали :))
какой протокол, какими вызовами читаете?

Клиент соединяется с сервером по TCP/IP и посылает данные отдельными пакетами, не получая подтверждение от сервера. При этом я столкнулся с тем, что при достаточно высоком темпе посылки передача данных прекращается и сервер просто висит на poll или recv, а посланные клиентом пакеты висят где-то в стеке серверного tcp (tcpdump показывает, что они пришли). Приём возобновляется при дальнейшей посылке пакетов или разрыве соединения. Пример: 30 пакетов послали, пришло 7, остальные висят и ждут событий. Что делать? Какие-нибудь опцуии сокета или способ синхронизации без изменения клиентов?

Почитайте про алгоритм отложенного подтверждения. При некоторых условиях возникает интерференция между алгоритмом Нейгла и отложенного подтверждения - скорее всего у вас как раз этот случай.

Сделайте размер буфера больше и делайте передачу только больших пакетов.

Спасибо за Ваш ответ, но я думаю, что дело в алгоритме Нейгла т.к пакеты достаточно большие и тем более, что я его отключил (пакеты пришли и висят в стеке TCP, а программа висит на poll после разрыва соединения я тутже их получаю). Я предпологаю, что следует использовать определенные опции при настройке сокета?

У меня была похожая ситуация - клиент и сервер реализовывал под Линухом и остаток пакетов доходил именно при разрыве соединения. Такое "поведение" по сей день для меня остается загадкой. "Поборол" сей эффект путем добавления \r\n каждому передаваемому сообщению. И еще в инете "нарыл" такую фигню - размер буфера на прием делается длиной в один символ (char). Чтение с помощью recv или read производится посимвольно, с накоплением в строку до тех пор - пока не получен терминатор ( например, тот же \r\n ).