hub2spoke

[ricky676]

I have the peer to peer rtmfp example in the SDK running (not locally) and sometimes it says that I am connected via RTMFP and sometimes using hub and spoke.

Is there anyway I can force the connection to only use rtmfp, and why does this sometimes show rtmfp and othertimes it doens't. It seems to be random. I tried restarting the router and rebooting,

Can anyone help? As I want rtmfp to be enabled or the app to say sorry busy etc.

[KeithStarling]

Peer-to-peer will not always be enabled when connecting via RTMFP, that's one of the features of this protocol is that it will attempt to use the best type of connection, switching between p2p and hub and spoke as appropriate for the network quality and room congestion.  It's probably not a good idea to not allow people in if they aren't connected via p2p, since there are plenty of situations where the user can connect fine, just not via p2p (through a VPN for example).

[ricky676]

Hi Keith

Thanks for your help.

I understand your points, however presume in my situation I had to force everyone that came to my app to use P2P only else  display a simple message saying service not available, is this possible?

Basically is there ANYTHING I can do to ensure that when a person comes to my app that they HAVE to use p2p?

Are you saying that even if we are setting the protocol in our code it is irrelevant, as it is not decided there?

Can you think of any creative solution for a way to achieve the above?

[KeithStarling]

The protocol does not mandate P2P, P2P is merely a feature of the protocol, which may or may not be utilized depending on the situation.  If you absolutely must require that users use P2P (which again, I do not advise, since this can really prevent a lot of people from using the application), there is a property on StreamManager (ConnectSession.primarySession.streamManager.isP2P).

[ricky676]

Again, thanks

I do understand your repeated suggestions on what I should and shouldn't be doing etc, however without going into detail this 'is' what I need to do for this particular app.

.isP2P returns the boolean  read only, which is fine, and I can use this to determine access to the app. However what I am trying to do is 'demand' a p2p connection despite network conditions (I know I know I know I know); rather than 'suggest' a p2p connection letting FMS decide what it thinks would be better at that time.

I would prefer a  really poor p2p connection than a great hub and spoke connection.

Currently I see this whole setup as analogous to a bandwidth checker for choosing the right streaming video to use; that you just can't turn off or override because FMS thinks it knows best .

So my question is this:

Is overriding the FMS decision  without scripting on the FMS possible in anyway? (Even you think the  whole approach is a bad idea )

[KeithStarling]

In that case... nope, sorry   You can't do that.

[Former Community Member]

In general, we only set isP2P false when you cannot accomplish connecting via P2P. This happens more often than you'd expect - firewall issues, etc. There's a couple of paths here :

:: If a user comes in and cannot connect via RTMFP, disconnect.

:: If you find that a user succeeds in coming in via RTMFP, tries to receive a p2p stream, and can't, then have him disconnect.

Thing is, you often don't know if a user can use p2p until he tries. Even if everyone succeeds, after the 3rd stream subscriber or so, you'll find that your publishers become bogged down trying to pump out too much bandwidth, and p2p becomes a bad experience.

Is there a specific reason you only want to use p2p? Seems a little like choosing a technology before a use-case?

nigel

[esteimle]

I understand the argument about Peer to Peer failover, and why it's better to use LCCS.  You can't get through every NAT Firewall combo without using an intermediary server so use the failover feature to ensure you get a connection.  Of course when you failover you're now paying $0.49/GB instead of just $0.01 per hour (plus messaging costs of $.10/1K).   Also your latency for audio goes way up, and that's very apparent especially since the audio and video don't appear to be synced in LCCS.  So there's benefit, but there's cost and if you don't want to pay the cost no matter how fair or inline with industry standards that cost is, then you're going to design a system that only does peer to peer.

Ok that being said I don't understand why in my test environment Stratus gets through and sets up a peer to peer connection no problem but LCCS is coming back saying "User ericsteimle has firewall settings preventing P2P".   I verified this with wireshark.  Doing a Stratus video call I see my code connect to stratus, setup the peer to peer connection and then all the video data starts getting pumped using UDP from test machine 1 to test machine 2.   Doing a test call with my LCCS code I see TCP traffic flowing between what I assume is the LCCS server farm and my two test machines.

So my question is why is there a difference, and how do I make LCCS connect just as well as Stratus does?  I actually don't have a problem having the failover as a backup but it costs me real money and I want to make sure users are only using it when they absolutely have to.  Is the LCCS service more conservitive in it's determination of whether a peer to peer connection will go through (or is it tilted to go for the $0.49/GB option more often)?

Regards,
Eric Steimle

Test Envirnment info:
1 OSX Laptop talking to 1 Windows XP Atom machine with private network IP addresss.  Both are behind a single nat and firewall that our incubator provides.  Not sure of their exact configuration but I'm sure I could track down facilites and make them tell me...   Test code for stratus was the standard stratus video demo, but ported to use the Cairingorm framework.   Test code for the LCCS is my own.

[Former Community Member]

Hi Eric,

Can you share your debug output for a user connecting and failing? In theory, RTMFP should work either way (Stratus/LCCS), but there might be something goofy routing you to non-RTMFP servers. We'll take a look.

nigel

[Former Community Member]

Hi Eric,

Theoretically, your connection should be like Stratus. We do have certain restrictions on the number of streams that you can have with P2P and I am not aware of that exact detail of stratus about number of streams it supports. But as you said in your case, the fallback is happening due to some firewall setting, and we do that fallback only when till certain time , we poll but we are not able to receive the stream. So, ideally you should receive the stream if there is no firewall as you mentioned. Btw, you are able to get rtmfp for both machines right ?

As Nigel said, a debug output will be useful. But I will investigate why you are not receiving the stream and the firewall error is coming.

Thanks

Hironmay Basu

[esteimle]

Sorry for the delay had to run home.   Here's the debug output, let me know if I can get you anything

more.

Thank you,

Eric

[esteimle]

Thanks for the help as usual.   I'm not sure what you mean by "Btw, you are able to get rtmfp for both machines right ?"  If you mean in the Stratus test do I think both machines are talking to each other peer to peer using rtmfp then yes I think so.  It's the same air code on both machines, and when I look at the traffic using wireshark I see tons of udp traffic going back and forth between the two. 

Btw I went to my house and tried the same test with the office, same results.   Not that it matters, just another data point.  Here I'm behind an airport express.

Thank you,

Eric

[Former Community Member]

Hi Eric,

As usual, debug output FTW! What's going on here is that you seem to have left out

protocol = "rtmfp";

in your AdobeHSAuthenticator. For reasons that are too boring to get into here, you have to explicitly request to go RTMFP. And yes, the authenticator is a weird place to put it. Eventually, you won't have to ask, it'll just happen automatically for you.

give it a whirl - you might have to wait ~5 minutes for your existing rooms to unload, but after that your rooms should connect via RTMFP.

hope that helps

nigel

[esteimle]

Ah that did the trick, and wireshark confirmed the connection was peer to peer udp.   The latency also improved.  It's always that one line of code...

Thanks for the help!

-Eric