[linrad] Re: Testing MAP65 v0.8

[Joe Taylor <Princeton.EDU; joe@xxxxxxxxxxxxxxxx>]

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