[Spread-users] Retransmission and Connection Problems

Ryan Caudy caudy at jhu.edu
Sat Oct 4 14:38:22 EDT 2003

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.


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 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

More information about the Spread-users mailing list