Нужно прочитать все что есть в буффере сокета, т.е. все что пришло на данный момент. Можно конечно сделать recv на 10000 байт и посмотреть что пришло, но как-то некрасиво...к тому же буффер ему тоже надо будет создавать большой..собственно как это сделать?

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





в этом примере протокол построен таким образом, что клиентская сторона должна отправлять знак CTERM - признак окончания сообщения.

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

azesmcar, 
Лезем в opsuperlib, или просто смотрим функтяру :

(вертает количество байт, которые ща есть для чтения)

в opsuperlib еще куча всего, рекомендую 

я нашел ioctlsocket, но он только под виндоуз..ioctl его аналог под линукс или как? могу и макрос вставить в принципе для кроссплатформенности (ибо мне нужен кроссплатформенный код).
InvalidProperty, посмотрим какие еще будут варианты 

azesmcar, да я весь уши   

ЕМНИП размер приемного буфера у сокета можно получить через getsockopt(...,SO_RECVBUF,...). Ну а потом на неблокируемом сокете читать число байт равное размеру буфера.  В этом случае должен вычитываться весь буфер. Можно еще добавить select или иной механизм мультиплексирования чтобы в холостую не читать.

Только не понятно зачем такое требование ? Ведь как-только в приемном буфере сокета появится место - сразу начнут поступать новые данные... это учебная задача?

как зачем? пришли данные, которые мне нужно прочитать...сколько мне читать если я не знаю сколько их там?


и что? у меня протокол с нефиксированным размером сообщений, мне нужно прочитать все что пришло..


похоже? 

InvalidProperty,  EINTR возвращается если системный вызов был прерван до того как прочитан хотя бы один байт. Так что lseek у тебя не имеет смысла.

да, ступил я чего-то. Сенкс, vinick

Добавлено через 10 минут и 18 секунд

Откуда? А если их никто больше не передает и на том конце клиент ждет, когда придет ответ?


А как узнать, что в данный момент в буфере находится целое сообщение, а не его кусок? Я понимаю, что ТС это не учитывает по роду задачи, но мне интересно, как справиться с получением целого сообщения, если его длина неизвестна

Это сообщение отредактировал(а) InvalidProperty - 20.3.2009, 13:41

TCP-потоковый протокол - и он совершенно не знает, что он передает - это труба, в которую что-то выливают на другом конце - от 1-го байта до более 4 гигов
Разбираться должен с содержимым протокол верхнего уровня (как это делает например HTTP- парсит полученные данные и выуживает инфу.) - т.е. ваше приложение.
А потому есть только конец TCP-сессии - recv() возвращает 0.


Это сообщение отредактировал(а) Олег2005 - 20.3.2009, 15:43

Олег2005, итого, имеем, что кроме того, что я уже описал выше, ничего, в принципе, кардинально нового придумать нельзя. 

Это сообщение отредактировал(а) InvalidProperty - 20.3.2009, 15:53

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

InvalidProperty, 
Примерно так  
azesmcar, 
К сожалению, оптимизировать работу модулей стека - это не наша задача!
Они написаны и работают так, как написано в RFC.
Честно говоря, они справляются и пока мы не жалуемся - чему свидетельство и эти диалоги.

Это сообщение отредактировал(а) Олег2005 - 20.3.2009, 16:11

Это не оправдание 



Тебе нужно прочитать сообщение или содержимое внутреннего буфера сокета ? Это две совершенно разные и малосвязанные между собой вещи. Читай небольшими кусками, как сазал Олег2005, тебе все равно придется как-то буферизовать поток и дробить его на сообщения на прикладном уровне.



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

комрад, дык это ессесно.