network backend, PEEK + TRUNC fails for non-TCP sockets

[egranata]

While trying to get iiod / libiio to run over a UNIX socket/VSOCK (https://github.com/analogdevicesinc/libiio/issues/277) I ran into issues with the way the network backend does its I/O.

It looks like the backend is trying to optimize its network access by doing PEEKing reads, and then TRUNCating once it's satisfied it read a full command/response.

This works fine on TCP sockets, but - alas: if one is using a UNIX socket, TRUNC with a NULL buffer pointer does not work; and if one is using a VSOCK, PEEK mode is not supported

So, basically, one way or the other, it's not really feasible to use this optimization scheme on anything other than TCP sockets.

I was wondering if it would make sense to eschew using send/recv entirely, and instead wrap the socket file descriptor in a FILE*, and use fread/fwrite instead.

Any good libc would provide buffering, so we'd probably not lose too much in terms of performance, and it would allow to abstract away the peculiarities of different kinds of sockets instead using one unique common interface: the file

Thoughts?

[pcercuei]

I'd be very cautious about this. Using stdio bite us in the past and that's the reason why we switchted to file descriptors. What I'd suggest to do, is to set a flag if the PEEK or TRUNC fails, that tells IIOD to use a "safe path" (which would be reading the strings byte by byte).

[egranata]

I'd be very cautious about this. Using stdio bite us in the past and that's the reason why we switchted to file descriptors. What I'd suggest to do, is to set a flag if the PEEK or TRUNC fails, that tells IIOD to use a "safe path" (which would be reading the strings byte by byte).

Adding @gwendalcr for his awareness.

@pcercuei the path you suggest is basically what I have in my CL in the ChromeOS tree: https://chromium-review.googlesource.com/c/chromiumos/third_party/libiio/+/1719570

Gwendal and I were wondering about upstreaming the changes in our tree at one point or another. It sounds like you'd be more likely to welcome a patch that does the "safe path one byte at a time" vs. one that switches to libc FILE*

Just for my education, I'd be curious if you have any recollection of what issues you ran into with the libc buffering

[pcercuei]

From what I remember (and I may not remember correctly, it's been a while), the problem was that the libc would buffer per-line, which made the bison+flex generated parser hang during non-interactive sessions.