-----Original Message-----
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Sunday, October 24, 1999 4:46 PM
Subject: Re: dhcpd + sv2agw
>On 24 Oct, Cathryn Mataga wrote:
>
>> I suspect, that if MULTICAST does what I think it is supposed to do, that it might
>> be uniquely suited for ham radio links with low bandwidth. That is, say,
>> for doing something like a convers or irc type chat system, where the chat messages
>> were smart enough only to go down the routes where someone was listening,
>> and also only go down the route once, you know. That is maybe all those hard
>problems
>> are solved down in this code by clever PHd type people. Still, me I haven't
>> gotten it working yet with ethernet -- though I haven't put a lot of time into it,
>and it's
>> not a high priority for me.
>
>I've been thinking about precisely the same thing. I was originally
>thinking of modelling it on a hole-fill protocol like the pacsat
>broadcast protocol. I think that is still a good idea, but carried over
>a multicast medium.
>
>BBS forwarding (lots of BBS on one frequency), convers, irc, DX
>cluster, weather information sharing, all sorts of things. Anywhere
>where you need to flood information out to multiple users on one
>frequency.
Yeah, for people on the same frequency, doing BROADCAST, with the kernel changes
I showed earlier should work. Then you can just 'sbin/ifconfig broadcast 44.4.28.255'
for example, and send to that address (And you need to setsockopt also.).
Other programs just read from the broadcast
address. I've been doing exactly these tests just yesterday.
MULTICAST, that is "/sbin/ifconfig device multicast",
should, as I understand it, with a network of worldwide servers, be smart enough
only to forward to servers who have users who need the packets. It's like I open
one socket, write a packet, and either one computer or every computer on the
whole net could see that data.
I assume, how it might happen for hams, then is that people running Internet gateways
would
run mrouted on their systems. And then users on those lans could run existing
MULTICAST applications either from native Windows or on Linux. And, by my
understanding, say, if someone wanted to broadcast a radio show or something,
they'd open a single socket on the host machine, and write that voice data. And,
then the network would be responsible for distributing the information to everyone
who was listening. Maybe with slow ham networks, voice would be overkill, but
it should also work with text based stuff too. Like maybe chat rooms and things.
Try...
http://www.linuxdoc.org/HOWTO/Multicast-HOWTO.html
I think everything is in the Linux KERNEL to do multicast over RF, theoretically,
though I don't know how close it is to working. I do know the packets do go
through a bunch of code that looks like it's supposed to be for multicast
packets when they come in over ax25, so it looks like it should work. That
weird packet that comes out of Windows, to 224.0.0.2 is some kind of
multicast thing also.
It seems most of the multicast activity is on BSD, and
not linux -- but then the ax25 is all Linux and not BSD, so there you go.
If multicast isn't catastrophically dead for ax25, it'd be nice to find out,
so that we could have it turned on for 2.14 or something and try some
applications.
