Re: datagram vs stream sockets

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Sat, 11 Sep 2010 11:12:42 +0200
manu%netbsd.org@localhost (Emmanuel Dreyfus) wrote:

> 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.

Is this a "bug" inherent to the way FUSE itself works?  Or an artifact
of some FS-specific code used with FUSE?  Or really introduced by the
perfused(8) client-server protocol?

> - 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?

sendto(2) indeed, although connect(2) could be used first to allow
using write(2) afterwards.

> - perfused is supposed to fork on new mounts, and this seems
> incompatible with SOCK_DGRAM.

I don't immediately understand the problem with fork(2)+SOCK_DGRAM
sockets.

For AF_LOCAL protocols I had to write where synchroneous request/reply
messages were needed, I used SOCK_DGRAM sockets, assuming that it'd be
lighter than SOCK_STREAM.  However I also had to increase the
send/receive buffer size using setsockopt(2) as necessary, depending on
the maximum packet size the protocol supported.

This would probably be more complicated if you needed to support very
large blocks exceeding what the kernel allows to be sent/received
atomically though, and a custom fragmentation system would then have to
be used, I think.  Which SOCK_STREAM of course automatically solves...
-- 
Matt