tech-userlevel archive

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

Re: datagram vs stream sockets

> I have hit a problem with perfused(8) developement.  This daemon
> talks with FUSE filesystems over a socket, currently of SOCK_STREAM
> type.

Which protocol family?  PF_LOCAL?  Someone mentioned UDP, but PF_INET
strikes me as unlikely for this application.

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

IMO this is the appropriate place to fix this: the filesystem should
treat the stream sockets as, well, streams: it should not be making any
assumptions about record boundaries on read.  See also below.

> Pooka suggested moving to SOCK_DGRAM sockets, so that the FUSE
> filesystem cannot eat data beyond a frame using a single read() call.

As others have remarked, SOCK_DGRAM semantics are wrong for this
application.  SOCK_RDM and SOCK_SEQPACKET are a better fit, but from
what I've managed to find I get the impression each is pretty much dead
in the water.

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

You're smart enough that I find it notable you apparently don't even
consider having the filesystem treat a stream socket as the octet
stream it really is, not necessarily reflecting record boundaries on
write to record boundaries on read.  Is there some reason this is out
of the question?  It really strikes me as the Right Thing.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML      
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index