tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: datagram vs stream sockets

On Sat, 11 Sep 2010 11:12:42 +0200 (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

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

Home | Main Index | Thread Index | Old Index