Re: datagram vs stream sockets

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> [...] you apparently don't even consider having the filesystem treat
>> a stream socket as the octet stream it really is, [...]
> [...]

> What I do not grasp yet is how it works without bugs on Linux:

Oho.  That's an important piece I was missing: you are trying for
compatability at some level with implementations on the penguin.

> character devices are not datagram sockets.

Other mail in the thread leads me to think Linux has /dev/fuse which we
replace with an AF_LOCAL SOCK_STREAM socket.

This is the real problem.  The protocol is designed to work over an
interface sockets simply don't provide: a flow-controlled stream of
records with record boundaries preserved (device drivers hear about
write() record boundaries, and can reflect them to read() if they
choose).

The only options I see offhand that preserve API-level compatability
are (1) do a driver along the /dev/fuse lines ourselves and (2) arrange
for something like SOCK_SEQPACKET to work in AF_LOCAL, then use that.

A limited form of this could be achieved by wrapping read and write
with something that puts framing bytes around records so as to preserve
record boundaries through an underlying transport (AF_LOCAL
SOCK_STREAM) that does not inherently do so.  But it would be difficult
to make that work without breaking other uses of read and write in the
same code.

> Perhaps the kernel just checks that a frame is consumed before
> sending a new one?  Unfortunately I am unaware of such a posibility
> with stream sockets.

In general, it's not possible.  In the specific case of AF_LOCAL, it's
relatively easy, at least within the kernel, because the peer socket is
available for direct inspection.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B