Cliquem para experimentar. Espero que gostem.

Alguma duvida….

Numa máquina existem (teoricamente) 65.536 portas TCP que podem ser usadas pelas mais diversas aplicações/serviços, o que (teoricamente) poderíamos ter 65.536 aplicações/serviços distintos a correr em simultâneo na nossa máquina. Relembrando o que foi referido em artigos anteriores: o IP identifica a máquina e o porto identifica a aplicação/serviço. Além das portas TCP temos também 65.536 portas UDP (teoricamente).

Mas afinal qual a diferença entre usar o protocolo TCP ou o protocolo UDP?

Protocolo TCP

O TCP é o protocolo mais usado isto porque fornece garantia na entrega de todos os pacotes entre um PC emissor e um PC receptor. No estabelecimento de ligação entre emissor e receptor existe um “pré-acordo” denominado de Three Way Handshake (SYN, SYN-ACK, ACK).

Exemplo

Considerem por exemplo que querem transmitir um filme ou o ficheiro com um jogo que ocupa 800 MB. Esse ficheiro terá de ser partidos em partes mais pequenas (fragmentação), para que seja viável a  sua transferência para outro PC. Recorrendo ao protocolo TCP existe a garantia que todos os pacotes serão entregues e reordenados do outro lado (uma vez que podem ir por caminhos diferentes). Além disso, por cada pacote ou conjunto de pacotes (previamente definido), a máquina de destino confirma que recebeu essa informação ao emissor e no caso de falha de algum pacote, a máquina de destino procede ao emissor o pedido de retransmissão do(s) pacote(S) em falta.

Já pensaram se na transmissão do ficheiro do filme ou jogo de (800 MB) faltassem por exemplo apenas 2 k???? …bem, o receptor simplesmente não iria conseguir abrir esse ficheiro recebendo provavelmente a mensagem “ficheiro corrompido”.

Então e o UDP?

O UDP é um protocolo mais simples e por si só não fornece garantia na entrega dos pacotes. No entanto, esse processo de garantia de dados pode ser simplesmente realizado pela aplicação em si (que usa o protocolo UDP) e não pelo protocolo. Basicamente, usando UDP, uma máquina emissor envia uma determinada informação e a máquina receptor recebe essa informação, não existindo qualquer confirmação dos pacotes recebidos. Se um pacote se perder não existe normalmente solicitação de reenvio, simplesmente não existe.

Exemplo

Vamos a um exemplo comum. Imaginem que vão usar streaming de vídeo e áudio através da Internet e usam por exemplo o Skype como aplicação. Se estabelecerem uma ligação com um amigo vosso, vão notar que existem muitos pacotes na transmissão que se perdem…ouvem aquele barulho normal aquando das transmissões…”bluuup” ou a perda/bloqueio de imagem por alguns ms (milisegundos), o que é perfeitamente aceitável. Não teria muita lógica que a meio dessa transmissão a vossa aplicação parasse o streaming e fosse solicitar ao receptor pacotes perdidos…simplesmente começávamos uma conversa e a meio iríamos receber informações provavelmente daquilo que falamos no início.

Não é muito normal encontrar aplicações que usem exclusivamente o protocolo UDP, usando o exemplo do streaming existe sempre o recurso ao TCP para trocar informações de controlo, libertando o UDP apenas para o envio da informação.

Nota final: Tentou-se explicar de forma simples e abreviada as principais características do UDP e TCP. Contamos com os vossos comentários de forma a analisarem o mesmo e a darem dicas para novos artigos.

Fonte

Instruções:

1. na janela nr. 1 introduzir nome e clicar “Ligar”;
2. o mesmo deverá ser feito na janela nr. 2;
3. O “Meu ID” será atribuido automaticamente. Colocar este valor no “Peer ID” da outra janela;
4. Clicar “Estabelecer Conecção” após estes dois campos estarem preenchidos;
5. Iniciar conversa,

O video ainda não está a funcionar e existem algumas alterações a serem feitas, como o visual e uma secção de login/registo onde será atribuido o “Meu ID”.

Outras funcionalidades poderão ser implementadas de existir tempo.

Mais tarde todo o trabalho será disponibilizado para o público, de modo a que este o possa estudar. Será colocado na barra lateral na secção de Ficheiros (alojado pelo Box.net)

Para trabalhar com o stratus é fundamental ter instalado o Flash Player 10. Download

O Flex é uma das alternativas para criar uma aplicação. Download

É necessário ter uma developer key para aceder ao serviço. Adquirir uma

Exemplo de um código genérico:

//É necessário introduzir o serviço em questão e o developer key
private const StratusAddress:String = “rtmfp://stratus.adobe.com”;
private const DeveloperKey:String = “xpto”;
// NetConnection é uma classe que cria uma conecção bidirecional entre aplicações ou aplicação/servidor
private var netConnection:NetConnection;
//A classe NetStream cria uma conecção unidirecionaçl entre aplicações. Esta pode publicar uma “stream” utilizado o NetStream.publish() ou receber com o NetStream.play()
//NetStream para enviar dados
private var sendStream:NetStream;
//NetStream para receber dados
private var recStream:NetStream;
//função chamada por um botão
private function connectToStratus(event:Event):void {
//Inicia uma NetConnection
netConnection = new NetConnection();
//verifica o estado
netConnection.addEventListener(NetStatusEvent.NET_STATUS,onStratusConnect);
//conecta com as variaveis definidas
netConnection.connect(StratusAddress + “/” + DeveloperKey);
}
private function onStratusConnect(event:NetStatusEvent):void {
Alert.show(event.info.code);
//verifica o estado
if (event.info.code == “NetConnection.Connect.Success”) {
txtMyPeerId.text = netConnection.nearID;
//cria a NetStream para enviar, através de uma conecção directa
sendStream = new NetStream(netConnection,NetStream.DIRECT_CONNECTIONS);
sendStream.addEventListener(NetStatusEvent.NET_STATUS,onSendStreamHandler);
sendStream.publish(“mystream”);
}
}
//função chamada por um botão
private function connectToPeer(event:Event):void {
//cria a NetStream para receber
recStream = new NetStream(netConnection,txtOtherPeerId.text);
recStream.addEventListener(NetStatusEvent.NET_STATUS,onReceiveStreamHandler);
recStream.play(“mystream”);
recStream.client = this;
}
//objecto para tartar do texto
private var msgObject:Object = new Object();
//função chamada por um botão
private function sendChatMessage():void {
chatMessages.addChild(prepareLabel(“Tu: “, txtMsg.text));
msgObject.userName = userName.text;
msgObject.message = txtMsg.text;
sendStream.send(“receiveChatMessage”,msgObject);
txtMsg.text = ”;
}
private var messageLabel:Label;
//função para formatar o texto
private function prepareLabel(userName:String, message:String):Label {
messageLabel = new Label();
messageLabel.percentWidth = 100;
messageLabel.htmlText = “<br>”+userName+” : “+message;
return messageLabel;
}
//função que recebe o texto e o coloca no ecra
public function receiveChatMessage(msgObject:Object):void {
chatMessages.addChild(prepareLabel(msgObject.userName, msgObject.message));
}

For more information regarding Flash Player 10, Adobe Air 1.5 and RTMFP view our complete RTMFP FAQ posted on adobe.com at http://www.adobe.com/go/rtmfp_faq.

What is Peer to Peer (P2P)? Peer to Peer (P2P) has various meanings within the technology industry, but typically refers to the establishment of a direct connection between two or more end-users to aid in the movement of data and media.

There are several types of P2P solutions -

• End User to End User: Two clients communicate directly without passing their data through the server for low-latency, real-time communication. This is the solution that Adobe is enabling with RTMFP.

• Swarming: Many to many communication typically used to share delivery a file via download. Swarming maximizes transfer speed by gathering pieces of a file and downloading these pieces simultaneously from other end-users who already have them. Swarming solutions typically require a standalone application designed to locate and connect to other end-users’ computers that have the relevant content. These solutions typically have local file system access. Flash player 10 and AIR 1.5 will not enable swarming solutions.

• Multicast: One to many communication over an IP infrastructure. Multicast speeds content delivery and reduces the burden on the network because a source sends the data packet only once for delivery to a large number of end-users. The nodes in the network take care of replicating the packet to reach multiple end-users only where necessary. Flash Player 10 and AIR 1.5 will not enable multicast solutions.

For more information on Peer to Peer see Wikipedia at http://en.wikipedia.org/wiki/Peer-to-peer.

RTMFP uses P2P techniques to ensure a high quality delivery and efficient use of the network. It is a managed connection, which means it requires the authorization of a server to make the introductions. The client must be connected to the server to retain the direct connection.

What is Stratus?Stratus is a hosted rendezvous service that aids in establishing communications between Flash Players or Adobe AIR endpoints using RTMFP. Flash Player endpoints must stay connected to the server during the entire time of communications. Unlike Flash Media Server, Stratus does not stream video or support media relay, shared objects, or scripting. Stratus is being made available as a beta service through Adobe Labs to allow our developer community to begin building applications using RTMFP.

How do Stratus and a Flash Media Server (FMS) differ?When using Stratus, all data is sent directly from client to client. Flash Media Server supports client to server communication. Additionally features like shared objects and server side scripting that are supported by FMS are not supported with Stratus.

What do I need to use Stratus?You will need to sign in with your AdobeID to receive a unique Developer Key which will be used within your application to take advantage of Stratus. Then, get your Developer Key to gain access to the service.

How much does Stratus cost? Stratus is a free beta service. You will need to register with your Adobe ID to get a unique Developer Key.

When will a market-ready version of Stratus be released? Stratus is being deployed as a beta service to assess the functionality as well as market demand. Based on what we learn through the beta, we will determine our product roadmap moving forward with the service.

If I have trouble using Stratus, who should I contact for support? Please use the Labs user forums http://www.adobe.com/cfusion/webforums/forum/categories.cfm?forumid=72&catid=756&entercat=y. Adobe team members will be monitoring the forums.

What new functionality does Adobe Flash Player 10 and AIR 1.5 enable? By using RTMFP, applications that rely on live, real-time communications, such social networks and multi-user games will be able to deliver higher quality communication solutions. Flash Player 10 and AIR 1.5 will also enable end-users to connect and communicate directly with each other using their computer’s microphone and webcam. Flash Player 10 and AIR 1.5 will not support file or document sharing.

How will developers work with RTMFP? RTMFP enables developers to establish direct end user to end user peering communication between two or more clients running an application built for Adobe Flash Player or Adobe AIR for delivery of live, real-time media. RTMFP is similar to RTMP for client-server connections because RTMFP has full support for all the Flash Media Server functionality currently found in RTMP, including live streaming, recording and playback, shared objects, and remote function calls.

ActionScript developers will use ActionScript (2 or 3) to establish a NetConnection with the Stratus service. To make direct connections between Flash player 10 clients, new extensions have been added to the ActionScript class, NetStream, to establish a Flash Player as a publisher or subscriber.

What are the limitations of RTMFP in Flash Player 10 and AIR 1.5? Flash Player 10 and AIR 1.5 will not enable swarming, multicast or broadcast quality live video. It will only enable communication from the voice and video devices native to your computer (e.g. microphone and webcam) and enables application developers to send ActionScript data messages directly between Flash Player and Adobe AIR clients.

Does Adobe plan to expand the functionality of RTMFP? Adobe will continue to evaluate and evolve RTMFP to meet new market needs, however, there are no announcements at this time.

How will I make a P2P connection through Flash Player 10 or Adobe AIR 1.5?Connections from a SWF through an RTMFP-capable server will be assigned a temporary unique ID that is infeasible to guess or forge. Other SWFs connected to the same server can subscribe to the streams and events from that ID once the broadcasting SWF agrees to the connection.

On the server level, these IDs can be mapped to application-specific information such as presence. For a chat application, the ID can be linked to the nickname the user gave when connecting to the application. While the end-user may select the person that they want to chat with, Flash Player will use the ID to establish the connection with that user.

What can I send through the P2P connection?In a similar way that you would stream local microphone and webcam media up to a server, you will also be able to stream it directly to another Flash Player client that has connected as a peer.

Through NetStream.send you can also send data which is useful for shared experiences in real-time applications. Any data format can be sent through this method though there are size limitations to the packet which may make certain data types less useful.

How does the peer connection work?RTMFP UDP packets are sent directly from one Flash Player to another. The server translates the peer IDs to network addresses, and also assists in setting up the connection if one or both ends is behind a Network Address Translation (NAT) device. If UDP is blocked by a firewall or if RTMFP is blocked through a configuration of mms.cfg, the peer connection will not go through.

Can I choose between UDP and TCP?No, RTMFP is a UDP-based protocol while RTMP is a TCP-based protocol. You will automatically use UDP by calling the methods that work over RTMFP.

Can I get started with RTMFP now? Stratus allows you to begin developing RTMFP-enabled applications. It is available on Adobe Labs. You can also start using RTMFP with Cocomo.

When will application level multicast be available?Application level multicast was demonstrated at Adobe MAX Sneaks to demonstrate the future vision of Adobe around the RTMFP protocol, but no specific release plans or timelines are available at this time.

For more information regarding Flash Player 10, Adobe Air 1.5 and RTMFP view our complete RTMFP FAQ posted on adobe.com at http://www.adobe.com/go/rtmfp_faq

Fonte

O que é o P2P:

Peer-to-Peer (do inglês: par-a-par), entre pares, é uma arquitetura de sistemas distribuídos caracterizada pela descentralização das funções na rede, onde cada nodo realiza tanto funções de servidor quanto de cliente.

Exemplo de arquitectura P2P

O que é o RTMFP:

Real Time Media Flow Protocol (RTMFP) is a proprietary protocol developed by Adobe Systems. RTMFP enables direct peer-to-peer communication between multiple Adobe Flash Players and applications built using the Adobe AIR framework for the delivery of rich, live, real‐time communication.

By using RTMFP, applications that rely on live, real‐time communications, such social networks and multi‐user games will be able to deliver higher quality communication solutions. RTMFP enables end‐users to connect and communicate directly with each other using their computer’s microphone and webcam. RTMFP will not support file or document sharing. This solution enhances the current functionality in the Flash Player by creating a higher quality solution that will perform better regardless of variations in the network

O que é o UDP?

O User Datagram Protocol (UDP) é um protocolo simples da camada de transporte. Ele é descrito na RFC 768 e permite que a aplicação escreva um datagrama encapsulado num pacote IPv4 ou IPv6, e então enviado ao destino. Mas não há qualquer tipo de garantia que o pacote irá chegar ou não.

O protocolo UDP não é confiável. Caso garantias sejam necessárias, é preciso implementar uma série de estruturas de controle, tais como timeouts, retransmissões, acknowlegments, controle de fluxo, etc. Cada datagrama UDP tem um tamanho e pode ser considerado como um registro indivisível, diferentemente do TCP, que é um protocolo orientado a fluxos de bytes sem início e sem fim.

Também dizemos que o UDP é um serviço sem conexão, pois não há necessidade de manter um relacionamento longo entre cliente e o servidor. Assim, um cliente UDP pode criar um socket, enviar um datagrama para um servidor e imediatamente enviar outro datagrama com o mesmo socket para um servidor diferente. Da mesma forma, um servidor poderia ler datagramas vindos de diversos clientes, usando um único socket.

O UDP também fornece os serviços de broadcast e multicast, permitindo que um único cliente envie pacotes para vários outros na rede.

Cumprimentos,

Gonçalo Gonçalves