[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linrad] Re: Testing MAP65 v0.8
- Subject: [linrad] Re: Testing MAP65 v0.8
- From: Joe Taylor <Princeton.EDU; joe@xxxxxxxxxxxxxxxx>
- Date: Thu, 19 Jul 2007 11:45:55 -0400
Rick and all,
Well, it seems I'm learning more about computer networking
than I ever wanted to know... ;-)
Why did you use a mask of 224.0.0.0 instead of 240.0.0.0 in your
multicast route statement on the Linux box?
(Your: # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 statement.)
My mistake when typing it into the email message. I had it
right when the tests were made.
Unfortunately neither of the switches you tested with had the horsepower
(i.e. were managed switches) to control the multicast traffic, though
they will segment the unicast traffic.
Yes, this is exactly what I discovered.
You asked some more good questions, and I will follow up on
them soon.
In the meantime, I've realized that there is really no
reason to use multicasting for the Linrad --> MAP65
connection. I could just as well "unicast" the UDP data
stream between the two machines, using a crossover cable and
explicit private-LAN (192.168.x.x) addresses on each end,
and have none of the problems I've been worrying about.
This solution causes the data go where I want it to go, and
nowhere else.
The other option that I'm beginning to think very attractive
is running both Linrad and MAP65 in a single machine. TIMF2
data could go from Linrad to MAP65 over the loopback (lo)
interface -- or by way of shared memory, or ???
-- Joe, K1JT
#############################################################
This message is sent to you because you are subscribed to
the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to <linrad-request@xxxxxxxxxxxxxxxxxxxxx>
LINRADDARNIL