Struct rml_rtmp::handshake::Handshake

pub struct Handshake { /* fields omitted */ }

Struct that handles the handshaking process.

It should be noted that the current system does not perform validation on the peer's p2 packet. This is due to the complicated hmac verification. While this verification was successful when tested agains OBS, Ffmpeg, Mplayer, and Evostream, but for some reason Flash clients would fail the hmac verification.

Due to the documentation on the fp9 handshake being third party, the hmac verification was removed. It is now assumed that as long as the peer sent us a p2 packet, and they did not dicsonnect us after receiving our p2 packet, that the handshake was successful. This has allowed us to succeed in handshaking with flash players, and there are still enough checks that it should be unlikely for too many false positives.

Examples

use rml_rtmp::handshake::{Handshake, PeerType, HandshakeProcessResult};

let mut client = Handshake::new(PeerType::Client);
let mut server = Handshake::new(PeerType::Server);

let c0_and_c1 = client.generate_outbound_p0_and_p1().unwrap();
let s0_s1_and_s2 = match server.process_bytes(&c0_and_c1[..]) {
    Ok(HandshakeProcessResult::InProgress {response_bytes: bytes}) => bytes,
    x => panic!("Unexpected process_bytes response: {:?}", x),
};

let c2 = match client.process_bytes(&s0_s1_and_s2[..]) {
    Ok(HandshakeProcessResult::Completed {
        response_bytes: bytes,
        remaining_bytes: _
    }) => bytes,
    x => panic!("Unexpected s0_s1_and_s2 process_bytes response: {:?}", x),
};

match server.process_bytes(&c2[..]) {
    Ok(HandshakeProcessResult::Completed {
            response_bytes: _,
            remaining_bytes: _
        }) => {},
    x => panic!("Unexpected process_bytes response: {:?}", x),
}

Methods

impl Handshake

pub fn new(peer_type: PeerType) -> Handshake

Creates a new handshake handling instance.

The Flash Player 9 handshake requires generating a different packet 1 depending if you are the client or the server, and thus this must be specified when creating a new Handshake instance.

pub fn generate_outbound_p0_and_p1(&mut self) -> Result<Vec<u8>, HandshakeError>

Creates the packets 0 and 1 that should get sent to the peer. This is only strictly required to be called by the client in the connection process to initiate the handshake process. The server can wait until process_bytes() is called, and the outbound packets #0 and #1 will be included as the handshake's response.

For now this only sends a command byte of 3 (no encryption).

pub fn process_bytes(     &mut self,     data: &[u8] ) -> Result<HandshakeProcessResult, HandshakeError>

Processes the passed in bytes as part of the handshake process. If not enough bytes were received to complete the next handshake step then the handshake handler will hold onto the currently received bytes until it has enough to either error out or move onto the next stage of the handshake.

If the handshake is still in progress it will potentially return bytes that should be sent to the peer. If the handshake has completed it will return any overflow bytes it received that were not part of the handshaking process. This overflow will most likely contain RTMP chunks that need to be deserialized.

If the Handshake has not generated the outbound packets 0 and 1 yet, then the first call to process_bytes will include packets 0 and 1 in the response_bytes field.