Re: AX.25 Kernel - problem - ax25_sendmsg returns EMSGSIZE !

[Dave Platt <dplatt@radagast.org>]

>> What I want is to have SOCK_SEQPACKET reliable, accepting any amount of
>> data and on write returning number of bytes accepted. I do not care much
>> if fragmentation will take place or not, but currently I do not see any
>> reason why not.
> 
> I think you want SOCK_STREAM. You just want a byte stream which is
> arbitrarily split into packets; SOCK_DGRAM and SEQPACKET are intended
> for applications which care about packet boundaries.
> 
> Since SOCK_STREAM is apparently not so different from SOCK_SEQPACKET,
> perhaps you could implement it for AX.25?

I agree, that's probably the cleanest approach, and it ought not to be
very much work at all within the AX.25 layer.

On reading through the various man pages and looking at the code, I'm
frankly not sure why the Linux AX.25 implemented SOCK_SEQPACKET and
not SOCK_STREAM.  It looks to me as if the only substantial differences
between these two connection types are:

-  SOCK_STREAM is intended to allow writes of arbitrary amounts of data,
    and does not guarantee that the reader of the data received it in
    pieces whose boundaries correspond to those given by the writer.
    All of the data is guaranteed to be delivered, reliably and in
    sequence, or the connection will be broken.

-  SOCK_SEQPACKET is *not* defined to allow writes of arbitrarily
    large sizes... it's specifically defined to limit writes to a
    fixed maximum size (with the maximum size being connection-dependent,
    apparently).  Packets are guaranteed to get through the connection,
    reliably and in sequence, and the reader is guaranteed that each
    read will return data from precisely one sender-packet (i.e. if
    the network fragments them, the fragments must be reassembled
    before any of the data can be delivered).  If the reader requests
    less data than is present in an incoming packet, the reader gets
    only the amount asked for, and the remainder is discarded (!)
    rather than being delivered during a subsequent read.

These two methods use the same APIs, and should both be able to
run over AX.25 I packets.

I *think* that adding SEQ_STREAM to the AX.25 code, in addition to
SEQ_SEQPACKET in each of the places that it appears, would do most of
the work in adding support for this protocol.

As far as re-enabling packet fragmentation in the AX.25 packet
layer... seems to me that it would be legitimate to do so as long
as the lower-level code does the fragmentation properly (i.e.
breaking the write into small-enough chunks to fit within the
path's maximum frame length limit) and as long as the receiving
code does the reassembly properly.

Any app which uses SOCK_SEQPACKET, and wants to be able to write
arbitrarily-large amounts of data, had better be *very* sure that
its peer is issuing reads which are large enough to swallow the
largest-possible write!  Otherwise, data will be lost (according
to the semantics for SOCK_SEQPACKET).

That's why I'd favor using SOCK_STREAM for AX.25 connections (just
as TCP uses SOCK_STREAM) - there's no requirement with SOCK_STREAM
that the sender and receiver coordinate on the size of the largest
write operation.  This would seem to ease the software compatibility
problem quite a bit!