Re: datagram vs stream sockets

[Sad Clouds <cryintothebluesky%googlemail.com@localhost>]

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

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

This sounds like a design flaw.

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

But you still have the possibility of a fast sender overflowing the
receive, on UDP sockets that data will be silently discarded.

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

I don't know how FUSE works, but it seems like it runs on top of TCP,
however the application protocol it uses, lacks flow control. Maybe
there is way to redesign it so that TCP takes care of flow control? You
could pipeline a fixed number of frames to improve performance, however
if the sender overflows the receiver, TCP should take care of that.