Showing posts with label rtmp. Show all posts
Showing posts with label rtmp. Show all posts
Wednesday, December 17, 2014
RTMP Handshake
After establishing a TCP connection, an RTMP connection is established first performing a handshake through the exchange of 3 packets from each side (also referred as Chunks in the official documentation). These are referred in the official spec as C0-2 for the client sent packets and S0-2 for the server side respectively and are not to be confused with RTMP packets that can be exchanged only after the handshake is complete. These packets have a structure of their own and C1 contains a field setting the "epoch" timestamp but since this can be set to zero, as is done in third party implementations, the packet can be simplified. The client initialises the connection by sending the C0 packet with a constant value of 0x03 representing the current protocol version. It follows straight with C1 without waiting for S0 to be received first which contains 1536 bytes, with the first 4 representing the epoch timestamp, the second 4 all being 0, and the rest being random (and which can be set to 0 in third party implementations). C2 and S2 are an echo of S1 and C1 respectively, except with the second 4 bytes being the time the respective message was received (instead of 0). After C2 and S2 are received the handshake is considered complete.
Tuesday, December 16, 2014
Difference between rtmp and rtmfp
The principal difference is how the protocols communicate over the network.
RTMFP is based on User Datagram Protocol (UDP),[1] whereas Real Time Messaging Protocol (RTMP) is based on Transmission Control Protocol (TCP).
UDP‐based protocols have some specific advantages over TCP‐based protocols when delivering live streaming media, such as decreased latency and overhead, and greater tolerance for dropped or missing packets, at the cost of decreased reliability.
Unlike RTMP, RTMFP also supports sending data directly from one Adobe Flash Player to another, without going through a server. A server‐side connection will always be required to establish the initial connection between the end‐users and can be used to provide server‐side data execution or gateways into other systems. The user of a Flash Media Server will also be required to authorize network address lookup and NAT traversal services for the clients to prevent Flash Player from being used in an unmanaged way.
RTMFP is based on User Datagram Protocol (UDP),[1] whereas Real Time Messaging Protocol (RTMP) is based on Transmission Control Protocol (TCP).
UDP‐based protocols have some specific advantages over TCP‐based protocols when delivering live streaming media, such as decreased latency and overhead, and greater tolerance for dropped or missing packets, at the cost of decreased reliability.
Unlike RTMP, RTMFP also supports sending data directly from one Adobe Flash Player to another, without going through a server. A server‐side connection will always be required to establish the initial connection between the end‐users and can be used to provide server‐side data execution or gateways into other systems. The user of a Flash Media Server will also be required to authorize network address lookup and NAT traversal services for the clients to prevent Flash Player from being used in an unmanaged way.
Comparison of TCP and UDP
Transmission Control Protocol is a connection-oriented protocol, which means that it requires handshaking to set up end-to-end communications. Once a connection is set up, user data may be sent bi-directionally over the connection.
- Reliable – TCP manages message acknowledgement, retransmission and timeout. Multiple attempts to deliver the message are made. If it gets lost along the way, the server will re-request the lost part. In TCP, there's either no missing data, or, in case of multiple timeouts, the connection is dropped.
- Ordered – If two messages are sent over a connection in sequence, the first message will reach the receiving application first. When data segments arrive in the wrong order, TCP buffers delay the out-of-order data until all data can be properly re-ordered and delivered to the application.
- Heavyweight – TCP requires three packets to set up a socket connection, before any user data can be sent. TCP handles reliability and congestion control.
- Streaming – Data is read as a byte stream, no distinguishing indications are transmitted to signal message (segment) boundaries.
User Datagram Protocol is a simpler message-based connectionless protocol. Connectionless protocols do not set up a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction from source to destination without verifying the readiness or state of the receiver.
- Unreliable – When a UDP message is sent, it cannot be known if it will reach its destination; it could get lost along the way. There is no concept of acknowledgement, retransmission, or timeout.
- Not ordered – If two messages are sent to the same recipient, the order in which they arrive cannot be predicted.
- Lightweight – There is no ordering of messages, no tracking connections, etc. It is a small transport layer designed on top of IP.
- Datagrams – Packets are sent individually and are checked for integrity only if they arrive. Packets have definite boundaries which are honored upon receipt, meaning a read operation at the receiver socket will yield an entire message as it was originally sent.
- No congestion control – UDP itself does not avoid congestion, unless they implement congestion control measures at the application level.
- Broadcasts - being connectionless, UDP can broadcast - sent packets can be addressed to be receivable by all devices on the subnet.
Labels:
internet,
networking,
rtmp,
rtp,
streaming,
tcp,
udp,
web services,
web technology
Subscribe to:
Posts (Atom)
