datagram vs stream sockets

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Hello

I have hit a problem with perfused(8) developement. This daemon talks
with FUSE filesystems over a socket, currently of SOCK_STREAM type.
Every time the kernel issue a filesystem operation, perfused(8) will
produce a frame containing a FUSE operation and send it over the socket.

On the FUSE filesystem end, read() is used to read frames, using a huge
length parameter. If perfused sends frames faster than the filesystem
consumes them, then multiple frames will be readen at once, and the
filesystem will  discard anything beyond the first one. Discarded frames
get no reply at all, producing a hang in the process that caused the
file operation.

Pooka suggested moving to SOCK_DGRAM sockets, so that the FUSE
filesystem cannot eat data beyond a frame using a single read() call. I
run into several problems:
- the FUSE filesystem uses write() on the socket, and it seems that data
never reach the other end. I assume that sendto() must be used with
SOCK_DGRAM sockets, instead of write(). Opinions?
- perfused is supposed to fork on new mounts, and this seems
incompatible with SOCK_DGRAM.

The alternative is to keep SOCK_STREAM, and make sure that no frame is
sent before we get a reply to the previous frame. This cause a
performance hit, and it will not fix the problem for file operation that
have no reply.

For now, I am stuck with that problem. Anyone has some ideas about how
to move forward? 

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost