[C, socket] Как узнать какой объём данных доступен для чтения?

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

В Solaris то ли 10, то ли 9 FIONREAD возвращает неверное значение. По слухам это вообще болезнь коммерческих Юниксов. Мне кажется, что лучше не пользоваться совсем. Не могу придумать задачу, где FIONREAD будет настолько уж полезен.

В сорляре есть port_get со всеми вытекающими. Топикстартер, возьми libevent.

длину сообщения не надо определять, надо использовать non-blocking read

> Это нормальный путь решения задачи

ioctl не кошерен, если нужна переносимость - лучше poll/select а затем recv до тех пор пока есть входные данные.

>узнать длину сообщения, лежащего в приёмном буфере сокета
она как бы не всегда постоянная)

Присоединяюсь к Reset, расскажи в чём задача. Если твоя цель добиться того чтобы не было блокировок на чтение то тупо делаешь non-blocking io и читаешь пока не вернётся EAGAIN.

> Присоединяюсь к Reset, расскажи в чём задача.
Задача проще некуда.
1. Есть сервер. Стартует и создаёт сокет AF_UNIX, SOCK_DGRAM.
2. Есть клиент, который подцепляется к этому сокету и шлёт на него команды.
3. Сервер получает команду, делает работу, обратно в сокет выдаёт результат.
4. Клент, после того как отослал команду, по POLLIN ждёт появления данных на сокете....
.... когда данные появились вызывается ioctl с IFNOREAD для определения обёма, выделяется массив, данные читаются....
.... и вываливаются пользователю. Сервер не вываливает ответ потому как это демон - он пересылает их кленты.

На много ли выиграет прложение, есл под клиентский массив для ответа память не будет выделяться динамически, а будет статический массив, в который инфа с сокета будет читаться до победного конца и вываливаться, соответственно кусками?

* FIONREAD, клиенту...
спать пора :)

> На много ли выиграет прложение, есл под клиентский массив для ответа память не будет выделяться динамически, а будет статический массив, в который инфа с сокета будет читаться до победного конца и вываливаться, соответственно кусками?

Как минимум так меньше гемора с памятью :). Я у себя сделал так: есть буфер 4кб. Если ответ влезает то всё ок. Если не влезает то делаю его ресайз. А у тебя, я так понимаю, и так небольшие данные(ибо по условию задачи они целиком влезают буфер сокета). Следовательно статический буфер то что нужно.

ЗЫ где-то видел опцию у tcp которая позволяла бы с tcp-соединением работать не как потоком а как с пакетами. Т.е. если сделал send на 5кб данных то принимающая сторона за один read всё примет(или вернёт EAGAIN если не всё пришло). Но что-то найти это не могу.

Йо, это, похоже, MSG_WAITALL. Хз как оно с tcp дружит, если протестишь буду признателен :)

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