On Wed, Apr 28, 1999 at 02:26:40PM +0000, Julian Munoz Dominguez wrote:
>
> AX25 is not prepared to support compression. Because compression "needs"
> a kind
> of negotiation. Brian ko4ks and Thomas A. Moulton W2VY (Uhm, not sure it
> was him)
> have done a study about that. The solution was to modify a bit the ax25
> protocol, using reserved bit for negotiation purposes.
>
> Well, I think the better solution is to put an intermediate compression
> layer, just on the top of ax25. That is, some of the ax25 saps (= some
> of one of our callsigns+ssid) can be connected to this layer. All that
> using precedent studies, sure.
I don't see a problem with the compression negotiation. We "negotiate"
for a connection anyway, why not add a station supports compression bit
to the header and a this is compressed payload data bit? If both
stations transmit the station supports compression bit with the
uncompressed connection negotiation packets, then either station can
start transmitting compressed payload packets, secure in the knowledge
that the receiving station claims to support it. If the station
supports compression bit is off, then thing go on the way they are now.
Unconnected (UA) packets could be transmitted compressed or uncompressed,
with the default to uncompressed. This would mean the user has control
over the compression for UA packets and should realize the implications
of compressing them (not all stations may be able to decode the data).
>
> On the other hand, view from the computer (higher levels), this layer
> could have a similar interface than "pure" ax25, so just a new kind of
> socket could be created for that, with exactly the same behavior than a
> "pure" ax25 socket.
>
> Or even better, the compression layer could be called by the kernel when
> the client uses some predefined ax25 callsigns (callsigns that we want
> to use to connect to ax25 peers using compression), for example
> translating the systems calls in system calls for the compression layer.
>
> The interesting point would be to make possible have 2 ips interfaces on
> the same radio, an ip address for compressed operation, another for
> non-compressed. That means that both use the same broadcast callsign
> (QST-0).. Oh, another idea rises to my mind: we could define a special
> broadcast callsings (QST-1, QST-2), to do possible that several ip
> interfaces share the same link layer, witout interferences. Uhm, not
> sure of the consecuences of that.
>
Interesting, but I think multiple interfaces and or callsign/ssid 's will
confuse the users and create a huge support burden (or at least the need
for a very clear an well maintained FAQ). At the very least they will
create a great frustration factor until the user realizes that they are
trying to talk to a station using compression with an interface that
does not support it.
Pat
-------------------------------------------
Is fearr Gaeilge bhriste, n� B�arla cliste.
