Adobe Flash Player and Streaming without Server, Part 1: Peering Broadcasting
As is known, a recent update of Adobe Flash Player products to 10.1 and Adobe AIR to 1.5 versions caused a furore in presenting the new Real-Time Media Flow Protocol (RTMFP) . I will ask in advance not to confuse the above with the Real-Time Messaging Protocol (RTMP) for the use of which the Adobe Flash Media Server (FMS) was required on the side of the service server.
The developers promise that the protocol will have a low time delay when sending packets, but most importantly, the protocol is focused on the organization of a peering network .
Earlier versions of Flash Player used real-time data transfer via the RTMP protocol and required significant financial costs. For the operation of Adobe Flash Media Server (FMS), very expensive and whimsical hosting is required (up to renting a physical server, because there are a lot of resources for this whole business, and it is installed as a separate software mod into the server system).
RTMP is the best choice for streaming media, sharing of various data, or remote / simultaneous use.
So, back, the new protocol (RTMFP) has already received the name "peering", because There is no strict need for a third-party media server to run AIR and Flex applications. Why is it “strict”, because the server is there, but not the one that processes / stores multimedia and other data, but the one that only controls the sessions between clients (peers) and distributes the traffic.
As stated in the message of Jozsef Vass ( Joseph Vass, senior researcher at the Adobe / Flash Runtime Foundation, who previously worked for the innovative technology of VoIP ) “Cirrus service for developing end-to-end-to-end applications using RTMFP in Flash Player 10” “Cirrus service for developing final applications using RTMFP in Flash Player 10” ) in order to use RTMFP, the Flash Player Peer must connect to an RTMFP-compatible server, such as Cirrus (formerly codenamed Stratus ) or Flash Media Server 4. The article says that Cirrus is a network service that helps to install with ides between clients (peers) through their Flash Players. Based on the materials and applications of the article, a similar server can be organized on your web resource ( see the source code in the appendix, file “reg.cgi” ).
About the benefits of RTMFP
- the protocol is not controlled by the Transmission Control Protocol (TCP) because of its habit of re-sending lost data packets, but is based on the User Datagram Protocol (UDP) , which reduces the response time between clients (peers) and the server. In addition, UDP in most cases is not blocked by firewalls, which frees you from setting up firewalls;
- data is sent directly between two Flash Player clients in real time without routing through a central server;
- multimedia transmission is supported in high quality, exactly as much as the width of the Internet channel between two clients (peers) can afford;
- the presence of its, ie Adobovskoy flow control service Cirrus , at the address: rtmfp: //p2p.rtmfp.net, which checks the possibility of using the protocol by the developer key. Once again, I have nothing to do with Flash Media Server. Cirrus is used solely to enable Flash Player instances to find each other online.
- A secure connection is achieved through 128-bit AES using the Diffie-Hellmann key exchange method. SSL or RTMPS support.
- the presence of separate classes in ActionScript 3.0.
Peering Broadcast Organization
Before using Adobe Cirrus, you must obtain a developer key from Adobe Labs . Peers can communicate with each other without using Cirrus. This requires that clients be on the same local network, which is extremely rare.
To connect to the Adobe Cirrus service, you need to create a NetConnection instance. When connecting, 2 string parameters must be passed: Adobe Cirrus URL and your developer key, as shown below:
If a successful connection was made with Cirrus, NetStatusEvent.NET_STATUS will be assigned the “NetConnection.Connect.Success” property to the info.code property.
Notes: Currently the NetConnection.call () method is not supported when using Cirrus. Any NetConnection.call () call will be ignored by Cirrus. The developers recommend not using the NetConnection.call () method when using RTMFP with Cirrus, since this will increase the memory consumption of the client without the necessary functional effect.
Once the Flash Player instance successfully connects to the Cirrus service, it will receive a unique 256-bit peer_ID , which Cirrus will use to bind it to the client’s IP address and port number so that other Flash Player clients can connect to it.
The new Cirrus 2 server channel and Flash Player 10.1 can now be used to help build self-managed P2P networks without the need for a manual peer_ID exchange. This allows multiple Flash Player clients to communicate directly with each other in the most efficient way.
Next, a connection is established with the client (peer). Direct streaming is achieved using a unidirectional NetStream channel. And if you want two-way data transfer, each Flash Player client must create a NetStream to send and a NetStream to receive data:
The stream broadcaster can directly control those who can receive the data it broadcasts. When a client attempts to access a published stream, the onPeerConnect () method will be called ( by default, the implementation simply returns true) to the published NetStream and the peer has access to the data) to prevent this from happening, you can implement a client (peer) check for the rights to this stream on the object " accept ":
On the side of the broadcaster, the NetStream.peerStreams property is inherent in all subscribing feasts. For example, using the sendStream.send () method, the stream will be sent to all peers, but you can also stream to a specific recipient:
It is necessary to mention two more properties, these are NetConnection.maxPeerConnections and NetConnection.unconnectedPeerStreams .
NetConnection.maxPeerConnections - determines the number of peers allowed to connect to the broadcaster. By default, this property has a value of 8, but in practice it may be more. Each Flash Player client sends and receives two streams, thereby creating a complete network. Since the width of the Internet channel for download is usually much higher than the upload, it is necessary to be very careful not to overload the incoming channel from the subscribed peer.
NetConnection.unconnectedPeerStreams property, which contains in the array of peers not yet subscribed to the broadcast data stream. When subscribing to a syrup broadcast, the peer name goes from this array to the NetStream.peerStreams array.
')
All while this is all. The only thing I would like to add is that, like any curious person, I decided to check all the protocol features described above.
The check was carried out to determine the dependence of the Applications on the Sirrus Server.
On the Adobe Lab site, there is a good example: “ Cirrus Sample Application ”. Sources can be downloaded and parsed by the bones here: http://download.macromedia.com/pub/labs/cirrus/cirrus_app_assets_v5.zip
So, here, testing was conducted in the home network. At first I came from a laptop connected to the Internet via a stationary PC, registered in this demo from Adobe Laba, then did the same thing on a stationary PC, made a connection using registered names, and then disconnected access to the Intrnet network. The verdict, 15 minutes (apparently the live session of streaming data on peer_ID lives) excellent communication between two webcams installed on different machines. Such a local self-self-messenger on the knee.
All, good luck to all. Waiting for an invitation to the army Habra warriors. I often do not promise to post, but still ... I like to share interesting.
The developers promise that the protocol will have a low time delay when sending packets, but most importantly, the protocol is focused on the organization of a peering network .
Earlier versions of Flash Player used real-time data transfer via the RTMP protocol and required significant financial costs. For the operation of Adobe Flash Media Server (FMS), very expensive and whimsical hosting is required (up to renting a physical server, because there are a lot of resources for this whole business, and it is installed as a separate software mod into the server system).
RTMP is the best choice for streaming media, sharing of various data, or remote / simultaneous use.
So, back, the new protocol (RTMFP) has already received the name "peering", because There is no strict need for a third-party media server to run AIR and Flex applications. Why is it “strict”, because the server is there, but not the one that processes / stores multimedia and other data, but the one that only controls the sessions between clients (peers) and distributes the traffic.
As stated in the message of Jozsef Vass ( Joseph Vass, senior researcher at the Adobe / Flash Runtime Foundation, who previously worked for the innovative technology of VoIP ) “Cirrus service for developing end-to-end-to-end applications using RTMFP in Flash Player 10” “Cirrus service for developing final applications using RTMFP in Flash Player 10” ) in order to use RTMFP, the Flash Player Peer must connect to an RTMFP-compatible server, such as Cirrus (formerly codenamed Stratus ) or Flash Media Server 4. The article says that Cirrus is a network service that helps to install with ides between clients (peers) through their Flash Players. Based on the materials and applications of the article, a similar server can be organized on your web resource ( see the source code in the appendix, file “reg.cgi” ).
About the benefits of RTMFP
- the protocol is not controlled by the Transmission Control Protocol (TCP) because of its habit of re-sending lost data packets, but is based on the User Datagram Protocol (UDP) , which reduces the response time between clients (peers) and the server. In addition, UDP in most cases is not blocked by firewalls, which frees you from setting up firewalls;
- data is sent directly between two Flash Player clients in real time without routing through a central server;
- multimedia transmission is supported in high quality, exactly as much as the width of the Internet channel between two clients (peers) can afford;
- the presence of its, ie Adobovskoy flow control service Cirrus , at the address: rtmfp: //p2p.rtmfp.net, which checks the possibility of using the protocol by the developer key. Once again, I have nothing to do with Flash Media Server. Cirrus is used solely to enable Flash Player instances to find each other online.
- A secure connection is achieved through 128-bit AES using the Diffie-Hellmann key exchange method. SSL or RTMPS support.
- the presence of separate classes in ActionScript 3.0.
Peering Broadcast Organization
Before using Adobe Cirrus, you must obtain a developer key from Adobe Labs . Peers can communicate with each other without using Cirrus. This requires that clients be on the same local network, which is extremely rare.
To connect to the Adobe Cirrus service, you need to create a NetConnection instance. When connecting, 2 string parameters must be passed: Adobe Cirrus URL and your developer key, as shown below:
private const CirrusAddress:String = "rtmfp://p2p.rtmfp.net";
private const DeveloperKey:String = "your-developer-key";
private var netConnection:NetConnection;
netConnection = new NetConnection();
// (listener)
netConnection.addEventListener(NetStatusEvent.NET_STATUS, netConnectionHandler);
// Cirrus
netConnection.connect(CirrusAddress, DeveloperKey);
If a successful connection was made with Cirrus, NetStatusEvent.NET_STATUS will be assigned the “NetConnection.Connect.Success” property to the info.code property.
Notes: Currently the NetConnection.call () method is not supported when using Cirrus. Any NetConnection.call () call will be ignored by Cirrus. The developers recommend not using the NetConnection.call () method when using RTMFP with Cirrus, since this will increase the memory consumption of the client without the necessary functional effect.
Once the Flash Player instance successfully connects to the Cirrus service, it will receive a unique 256-bit peer_ID , which Cirrus will use to bind it to the client’s IP address and port number so that other Flash Player clients can connect to it.
The new Cirrus 2 server channel and Flash Player 10.1 can now be used to help build self-managed P2P networks without the need for a manual peer_ID exchange. This allows multiple Flash Player clients to communicate directly with each other in the most efficient way.
Next, a connection is established with the client (peer). Direct streaming is achieved using a unidirectional NetStream channel. And if you want two-way data transfer, each Flash Player client must create a NetStream to send and a NetStream to receive data:
//
private var sendStream:NetStream;
sendStream = new NetStream(netConnection, NetStream.DIRECT_CONNECTIONS);
sendStream.addEventListener(NetStatusEvent.NET_STATUS, netStreamHandler);
sendStream.publish("media");
sendStream.attachAudio(Microphone.getMicrophone());
sendStream.attachCamera(Camera.getCamera());
//
private var recvStream:NetStream;
recvStream = new NetStream(netConnection, id_of_publishing_client);
recvStream.addEventListener(NetStatusEvent.NET_STATUS, netStreamHandler);
recvStream.play("media");
The stream broadcaster can directly control those who can receive the data it broadcasts. When a client attempts to access a published stream, the onPeerConnect () method will be called ( by default, the implementation simply returns true) to the published NetStream and the peer has access to the data) to prevent this from happening, you can implement a client (peer) check for the rights to this stream on the object " accept ":
var o:Object = new Object();
o.onPeerConnect = function(subscriberStream:NetStream):Boolean {
if (accept) {
return true;
} else {
return false;
}
}
sendStream.client = o;
On the side of the broadcaster, the NetStream.peerStreams property is inherent in all subscribing feasts. For example, using the sendStream.send () method, the stream will be sent to all peers, but you can also stream to a specific recipient:
sendStream.peerStreams[i].send();
It is necessary to mention two more properties, these are NetConnection.maxPeerConnections and NetConnection.unconnectedPeerStreams .
NetConnection.maxPeerConnections - determines the number of peers allowed to connect to the broadcaster. By default, this property has a value of 8, but in practice it may be more. Each Flash Player client sends and receives two streams, thereby creating a complete network. Since the width of the Internet channel for download is usually much higher than the upload, it is necessary to be very careful not to overload the incoming channel from the subscribed peer.
NetConnection.unconnectedPeerStreams property, which contains in the array of peers not yet subscribed to the broadcast data stream. When subscribing to a syrup broadcast, the peer name goes from this array to the NetStream.peerStreams array.
')
All while this is all. The only thing I would like to add is that, like any curious person, I decided to check all the protocol features described above.
The check was carried out to determine the dependence of the Applications on the Sirrus Server.
On the Adobe Lab site, there is a good example: “ Cirrus Sample Application ”. Sources can be downloaded and parsed by the bones here: http://download.macromedia.com/pub/labs/cirrus/cirrus_app_assets_v5.zip
So, here, testing was conducted in the home network. At first I came from a laptop connected to the Internet via a stationary PC, registered in this demo from Adobe Laba, then did the same thing on a stationary PC, made a connection using registered names, and then disconnected access to the Intrnet network. The verdict, 15 minutes (apparently the live session of streaming data on peer_ID lives) excellent communication between two webcams installed on different machines. Such a local self-self-messenger on the knee.
All, good luck to all. Waiting for an invitation to the army Habra warriors. I often do not promise to post, but still ... I like to share interesting.
Source: https://habr.com/ru/post/130526/
All Articles