[Spread-users] Retransmission and Connection Problems

[Ryan Caudy]

When you sent your configuration before, it said that you had 
'DangerousMonitor' set to 'false' (the default).  Set it to 'true', and 
the monitor should work fine.

--Ryan

Jeremy McDermond wrote:

> On Thursday, October 2, 2003, at 10:35 PM, Jonathan Stanton wrote:
> 
>> This is only a quick reply now as it's 1:30am and I'm really crashing.
>>
> 
> I know how that goes...
> 
>> I have seen a number of issues with multi-homed machines. Sometimes they
>> work just fine, sometimes they can work if configured (either Spread
>> configuration, or networking) and sometimes they seem to have problems
>> because of OS issues (usually Linux -- hopefully FreeBSD doesn't have the
>> same problems).
>>
> 
> I don't know if this is the same as Linux, but it seems that the 
> multicast packets go out the interface with the default route, unless 
> otherwise specified.  This is probably the "correct' behavior as far as 
> the OS is concerned. , and I feel pretty boneheaded for not 
> realizing/checking this before.  I configured a router for 225.0.1.1 to 
> get pushed through the correct interface and everything started looking 
> okay.
> 
>> My experience has been that multicast with multihomed machines can be
>> tricky because often only one interface is assigned to route multicast
>> packets and so if it isn't the right one (meaning the one the Spread
>> configuration is using) then nothing works.
>>
>> Broadcast usually works in these cases though, as the bcast address is
>> network address specific so it gets routed out the right interface.
>>
> 
> It appears that possibly there's some sort of broadcast limiting or 
> other weirdness on our network that seems to be making broadcast not 
> work correctly.
> 
>> The D, C, spread network configuration syntax was designed to deal with
>> multihomed machines, so it could help specify the bindings more 
>> precisely,
>> but if the machines are all on the same network it should not be
>> 'necessary'.
>>
> 
> I did this just in case, it wasn't that hairy a change to make.
> 
>> I'd run 'netstat -tan' and 'netstat -rn' while the spread daemons are up
>> and check the interfaces they are bound to and listening on, and the
>> routing table and make sure it all matches up. If you can post them I'll
>> take a look tomorrow and see if I notice anything.
>>
>> The 'spsend' and 'sprecv' programs that are part of the spread source 
>> (but
>> not built by default -- run 'make testprog' in a ./configured tree) send
>> the same kind of unicast, broadcast, and multicast UDP packets that 
>> Spread
>> itself does and can verify whether the networking is working without
>> running all of Spread.
>>
> 
> The spsend and sprecv programs are great, and invaluable.  They helped 
> me find my problems with
>     1) firewall rulesets
>     2) multicast routing
> in pretty quick order.  Thank you very much for pointing these out to me.
> 
> The apache daemons seem to be connecting correctly now, and shoving log 
> records into the log receivers, and spuser seems to work great.  For 
> some reason spmonitor is failing to execute.  It gets through its 
> banner, and up to the point at which it relenquishes permissions, and 
> then exits.  It seems to be exiting with a return code of 1, and I can't 
> find anywhere in the monitor code where it would do this.
> 
> 
>> Hope this helps some,
>>
> 
> Thank you immensely, this helped very much!
> 
>> Jonathan
>>
> -- 
> Jeremy C. McDermond                                                     
>   mcdermj at peak.org
> Lead Engineer
> Peak Internet, LLC                                                      
>                 (541) 738-4921
> 
> 
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
> 

-- 
Ryan W. Caudy
Center for Networking and Distributed Systems
Department of Computer Science
Johns Hopkins University