1 person found this helpful
nothing on the RTMFP side (none of the peers, and not Stratus) do reverse DNS lookups. your problem isn't a direct result of not having reverse DNS (or a local hostname set). however, it's possible that the not-having-reverse-DNS (what i assume you mean by "not having hostnames, but only IP addresses) is another symptom, or at least an indicator, of some other network condition that may be affecting these hosts' ability to quickly join a group.
Stratus's automatic group bootstrap function works by commanding *other* members of the group to connect to the new joiner. if the new joiner (with "no hostname") is behind a symmetric NAT and most other more normal members are behind port-restricted NATs (or a port-restricting firewall), then the new joiner won't be able to connect (or be connected to). if your "off campus" member isn't NATted or firewalled, it may be the "enough people can connect to it" host that the "no hostname" joiner can get connected up.
for any new joiner, Stratus (currently -- this could change) commands up to six other members (but no less than two) at random to connect. if your group is smaller than 6 and one of the members is "in the clear", then the "in the clear" one will most likely be one of the ones to try to connect to the new joiner.
your experience with "4-5 minutes to join" for the problem host is probably "the initial bootstrap failed, but at a later time it was commanded at random to join up to another new joiner, and that one was connect-to-able".
Thanks for your response! Fascinating and very helpful.
The 4-to-5 minute problem still perplexes me, however. Since it was a closed test, no new peers joined for it to start working, so the peer and the publisher were clearly able to communicate with each other…eventually.
Our setup: we have a desktop machine in our building that is putting out data to a stream continuously. We consistently get 8-to-11 second join times within our office building. Two of us took our two laptops across the street to another building. We connected one and it took a few minutes to join. We connected both and it took each of them a few minutes to join. When the off-campus person joined from their house, and then we joined from the building where it was previously slow to connect, we got back to the normal joining times of 8-11 seconds. When he disconnected a few seconds later, we were still getting our data flawlessly. So it seems like these devices can communicate with each other, they just need some outside help. I don’t understand how this is possible given the NAT and Firewall concerns that you’ve outlined, above.
Incidentally, the two laptops we brought across the street were unable to videophone (http://labs.adobe.com/technologies/stratus/samples/) each other while we were there. We can both videophone from in our building, however.
Would it be safer if we just kept a peer outside of the network at all times to act as a bootstrap? Would having one peer on the outside help facilitate these connections and let us scale to hundreds of users?
Thank you so much again for your helpful response.
the two computers unable to VideoPhoneLabs with each other suggests the "other building" has a symmetric NAT which means, in general, P2P communication will be spotty at best there. especially when every peer is behind some kind of NAT.
even when nobody new is joining a group, Stratus will occasionally command members at random to connect to other members at random to try to heal group partitions. your group is (the very definition of) partitioned in your problem state.
having an extra peer "outside" will only help if your groups are small; otherwise it's just luck of the draw who the in-the-clear peer will be commanded to connect to (or be the target for a peer that would otherwise be having problems).
If we permanently added the outside server (or n servers, where n is hopefully not too large) as bootstrap peers on the groupspec, would that help, or force the initial connection?
yes, that could help.