Skip to main content
A
Anonymous
November 19, 2011
Question

Please define "RTMFP P2P introductions"

  • November 19, 2011
  • 2 replies
  • 2523 views

Hi,

The following web page defines limits within FMS for something called "RTMFP P2P introductions":

http://www.adobe.com/products/flashmediaserver/helpmechoose.html

i.e. 500 or 15,000 depending on the version.

However, I really don't understand what this means and i have searched around everywhere but it doesn't seem to be explained.

Basically, I am considering developing a P2P video application that accross a global site could potentially have millions of sessions running simultaneously. And obviously, a 15k limit seems rediculously small if this imposes a limitation on the number of sessions that could be taking place. These would be using P2P Application Multicast using groupspecifier as defined in this article: http://www.adobe.com/devnet/flashmediaserver/articles/p2p_rtmfp_groups.html

And this is contrasted directly with statements by the Cirrus/Stratus team, and what it's capabilities are, which appear to be unlimited:

Adobe Stratus, the hosted RTMFP rendezvous service, can handle a very large number of simultaneous users.  it is limited only by the number of computers we currently have in our cluster, and we can increase its capacity by adding more physical computers.http://forums.adobe.com/message/2596084#2596084

Now from what I have read, the rendezvous service is utilized for firewall punchthrough / NAT traversal. This would be necessary for my application as I could have customers behind firewalls.

So what I want to know is if this 500/15K limit is imposed on managing the NAT traversal clients (even though data is being sent through the P2P group, not the server) for the lifetime that they exist as part of the P2P group, or does the limit only apply to the initiation of the connection to the P2P group, and once they are connected, they do not take up a spot in the 500/15k number.

If it is for the lifetime of the membership in the P2P group then my desired application would not be feasible with FMS, and only with Cirrus/Stratus - except that is not available as a commercial offering.

Can someone please clarify on this for me?

Thanks.

This topic has been closed for replies.

2 replies

M
Adobe Employee
Michael Thornburgh
Adobe Employee
November 21, 2011

it's my understanding that the 500/15000 limit is on the number of concurrent RTMFP connections to the server.

a "P2P introduction" is where the server helps get two peers talking by (invisibly inside RTMFP) converting a peer ID to one or more IP addresses and UDP port numbers, and by forwarding an Initiator Hello message from the connecting peer to the target peer (for NAT/firewall traversal/hole-punching). this introduction can only be done over an RTMFP connection to the server.

an RTMFP P2P NetStream is closed if its NetConnection is closed.

FMS performs the same "P2P introduction" and group bootstrap service that Cirrus (codename) does. however, FMS also does all the other FMS functions and is scriptable, whereas Cirrus *just* does P2P introduction and group bootstrapping. Cirrus is a highly specialized, purpose-built system optimized for its one task, whereas FMS is a much more general and broad-function tool.

A
Anonymous
November 21, 2011

Hi Michael, thanks for the info about the FMS intruction being the same as cirrus. That is good to know.

However, your reply has still not given me any clarity on the lifetime of a 'p2p introduction' and how this corresponds to the 500/15k limits.

Basically, NAT traveral works by party A (behind NAT 1), and party B (behind NAT 2) connecting to server S (cirrus / fms).

Server S observes the IP address and UDP port that each of A and B used to connect to server S.

Server S then tells A the IP address and UDP port that it observes B is using. Server S also tells B the IP address and UDP port that it observes A is using.

Then, simultaneously, A and B will initiate direct connections to each other's public IP address / UDP port that S discovered and told them about.

Thus, in the case of well behaving cone NATs, the connections initiated by A and B through their local routers to each other will map to the same public UDP ports as were used when the connection was made to S. A's new connection to B will punch through on the same UDP port that B just tried to use to connect to A, and thus a direct connection is established. Though if B for some reason has not yet tried to connect to A, A's packet may be dropped by B's router, however, B's packet (when it is eventually sent) to A will definitely get through because A had already sent off the initial request to B - and so a connection is established.

In the case of symmetric NAT there is trouble because each new outgoing request will get mapped to a new public UDP port, so this process can fail - though it can still work using a predictive approach - i.e. the symetric NAT may just increment the port by 1 from the port S observed when e.g. A tries to send it's packet to B (assuming A is behind a symetric NAT), in which case B when it tries to connect to A can try a few sequential UDP ports to guess what might be used next.

So anyway, this is what I would define as a 'p2p introduction' and it only needs to occur once to establish the connection between the peers, and doesn't have to persist for the entire period that the session is active.

I do however understand that in a p2p mesh, there can be many members - and 1 peer could for example be connected to up to 4 different peers thus requiring 4 p2p introductions to make that happen. And as new people are added to the mesh - or the mesh adjusts itself for performance reasons - peers may be introducted to each other that weren't previously connected etc.

But this still would not seem to require persistent usage for the entire length of the p2p session.

So if you could chat to your developers about how this works it would be great to get clarity on how these slots are taken up, and for how long.

Thanks.

M
Adobe Employee
Michael Thornburgh
Adobe Employee
November 21, 2011

as i explained, the 500/15,000 limit is on the number of concurrent RTMFP connections (connected clients) to the server.

a "P2P introduction", as you note, is an effectively instantaneous action, not a persistent one. however, these introductions are performed within the context of an RTMFP connection to the server.

the entry in the FMS comparison table labeled "RTMFP P2P introductions" i think refers to the number of clients that can be connected and for whom P2P introductions will be performed, and is not a limit on the number of introductions that will be performed.

what this limit means is, for example, on the Enterprise server with its 15,000 concurrent user limit, you could have 15,000 RTMFP connections to the server, and each of those 15,000 clients could be making any number of P2P connections to any of the other connected clients (but only to other clients that are connected).

other than performing the lookup and forwarding function, an RTMFP server (in its role as an RTMFP Redirector & Forwarder) has no idea how many (if any at all) direct P2P connections any of its connected clients have. in fact, the server has no idea if any requested P2P connection succeeded. those are features!

for more detail about what's really going on in RTMFP with a "P2P introduction", take a look at Matthew's presentation to the 77th IETF, pages 19-30:

   http://www.ietf.org/proceedings/10mar/slides/tsvarea-1.pdf

R
rower2k
Participant
November 21, 2011

+1

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices