RTMP – Real Time Messaging Protocol

byTouK
August 11, 2008
3 minute read

Protokół RTMP jest to zamknięty standard przemysłowy stworzony przez Adobe System. Jest używany do przesyłania obiektów AMF (Action Message Format) oraz danych w formie strumieniowej takich jaki audio i wideo pomiedzy klientem i serwerem Flash. RTMP do transportu wykorzustuje bezpośrednio protokół TCP/IP na porcie 1935 tunel HTTP na porcie 80 (RTMPT). Możliwe jest przesyłanie do 64 strumieni jednocześnie po tym samym połaczeniu. W kazdym pakiecie AMF znajduje sie numer identyfikujący strumien. Dana pakiet RTMP może zawierać wiele wiadmości AMF.

Pakiet RTMP

Pakiet rtmp składa się z nagłówka o stałej długości oraz o zmiennej długości zawartości. Długość nagłówka może przyjmować cztery wartości:

00 – 12 bajtów
01 – 8 bajtów
10 – 4 bajty
11 – 1 bajt

Krótsza długość nagłówka oznacza ze brakujace dane są takie same jak te wysłane w ostatnim pakiecie je zawierającym z tym samym object id.

Pierwszy bajt zawiera informacje o długości nagłówka oraz id obiektu. Długość nagłówka zawarta jest w pierwszych dwóch bitach a id obiektu w kolejnych 6. Id obiektu wskazuje na id wiadomości AMF powiązaną z danym strumieniem danych. Oznacza to ze możliwe jest przesłanie 64 typów obiektów czyli obsłużenie 64 strumieni w tym samym połaczeniu.

Kolejne trzy bajty zawierają timestamp, przesyłany zawsze gdy długość nagłówka jest wieksza/równa 4 bajty. Jego zastosowanie i znaczenie nie jest znane:)

Kolejne trzy bajty zawierają wielkość zawartości pakietu RTMP (bez nagłówka), domyślnie dla danych video oraz audio jest to 128 i 64 bajty. Natępujący bajt zawiera typ przkazywanego obiektu AMF.:

0x03 (Bytes Read) – wysyłany co x odebranych bajtów przez obie strony
0x04 (Ping) – używany do kontroli stanu strumienia, dzieli się na podtypy
0x05 (Server) – odpowiedzi serwera
0x06 (Client) – zapytania klienta
0x08 (Audio Data) – dane audio
0x09 (Video Data) – dane video
0x12 (Notify) – wywołanie nie oczekujące na odpowiedź
0x13 (Shared Object) – obiekt współdzielony, dzieli sie na podtypy
0x14 (Invoke) – wywołanie metody RPC na obiekcie zdalnym

Ostatnie cztery bajty zawierają id strumienia. Jeśli nadawca pakietu jest klient to zawierają one obiekt źródłowy ‘NetStream’, natomiast jeśli nadawcą jest serwer to zawierają obiekt ‘NetStream’ przypisany do tego strumienia po stronie serwera.

Połaczenie (Handshake)

Każde połaczenie inicjowane jest przez klienta. Inicjalizacja ma miejsce w oparciu o tzw ‘handshake’. Klient wysyła do serwera pojedyńczy bajt o wartości 0x03 i tablicę bajtów o długości 1536 oraz zapamiętuje zawartość tablicy. Serwer w odpowiedzi wysyła pojedyńczy bajt o wartośći 0x03 oraz dwie tablice bajtów o długości 1536. Zawartość drugiej tablicy jest kopią pierwszej tablicy wysłanej przez klienta. Klient porównuje zawartości tablicy i jeśli są zgodne wysyła do serwera ostateczne potwierdzenie w postaci pojedyńczego bajtu i tablicy bajtów o długości 1536 bedącej kopią pierwszej tablicy otrzymanej w odpowiedzi od serwera. Od tej pory połaczenie jest nawiązane.

Obiekty AMF

Po nawiązaniu połaczenia dane audio jak i video są przesyłane w obiektach używających struktury AMF. Format AMF jest wykorzystywany do przenoszenia klas LocalConnection, SharedObject, NetConnection, and NetStream. Wszystkie obiekty AMF są poprzedzone jedno bajtowym nagłówkiem lub nagłówkiem zgodnym z opakowującym nagłówkiem RTMP. Pierwsze bajt wskazuje na typ obiektu, zanczenie kolejnych bajtów zależy bezpośrednio od typu obiektu:

0x00 – 8 bajtów, liczba
0x01 – 1 bajt, wartość boolean
0x02 – string
0x03 – obiekt, jest to lista par typu klucz/wartość. Klucz jest reprezentowany jako String a wartość to obiekt AMF. Koniec obiektu jest wskazany za pomocą 0x000009 (parę o zerowej długości kluczu i wartości końca obiektu)
0x04 – film flash
0x05 – 0 bajtów, wartość NULL
0x06 – 0 bajtów, wartość niezdefioniowana
0x07 – referencja
0x08 – tablica ECMA
0x09 – 0 bajtów, koniec obiektu
0x0a – stala tablica
0x0b – data
0x0c – string wielobajtowy
0x0d – typ niewspierany
0x0e – zbiór rekordów
0x0f – obiekt XML
0x10 – obiekt typowany

TouK

— Previous article

SIP & SDP - Session Description Protocol

Next article —

Subtelny feature konstrukcji CONNECT BY

Spock, Java and Maven

byRafał Nowak
August 8, 2013

Few months ago I've came across Groovy - powerful language for JVM platform which combines the power of Java with abilities typical for scripting languages (dynamic typing, metaprogramming).

Together with Groovy I've discovered spock framework (https://code.google.com/p/spock/) - specification framework for Groovy (of course you can test Java classes too!). But spock is not only test/specification framework - it also contains powerful mocking tools.

Even though spock is dedicated for Groovy there is no problem with using it for Java classes tests. In this post I'm going to describe how to configure Maven project to build and run spock specifications together with traditional JUnit tests.

Firstly, we need to prepare pom.xml and add necessary dependencies and plugins.

Two obligatory libraries are:

<dependency>
    <groupid>org.spockframework</groupId>
    <artifactid>spock-core</artifactId>
    <version>0.7-groovy-2.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupid>org.codehaus.groovy</groupId>
    <artifactid>groovy-all</artifactId>
    <version>${groovy.version}</version>
    <scope>test</scope>
</dependency>

Where groovy.version is property defined in pom.xml for more convenient use and easy version change, just like this:

<properties>
    <gmaven-plugin.version>1.4</gmaven-plugin.version>
    <groovy.version>2.1.5</groovy.version>
</properties>

I've added property for gmaven-plugin version for the same reason ;)

Besides these two dependencies, we can use few additional ones providing extra functionality:

cglib - for class mocking
objenesis - enables mocking classes without default constructor

To add them to the project put these lines in <dependencies> section of pom.xml:

<dependency>
    <groupid>cglib</groupId>
    <artifactid>cglib-nodep</artifactId>
    <version>3.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupid>org.objenesis</groupId>
    <artifactid>objenesis</artifactId>
    <version>1.3</version>
    <scope>test</scope>
</dependency>

And that's all for dependencies section. Now we will focus on plugins necessary to compile Groovy classes. We need to add gmaven-plugin with gmaven-runtime-2.0 dependency in plugins section:

<plugin>
    <groupid>org.codehaus.gmaven</groupId>
    <artifactid>gmaven-plugin</artifactId>
    <version>${gmaven-plugin.version}</version>
    <configuration>
        <providerselection>2.0</providerSelection>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
                <goal>testCompile</goal>
            </goals>
        </execution>
    </executions>
    <dependencies>
        <dependency>
            <groupid>org.codehaus.gmaven.runtime</groupId>
            <artifactid>gmaven-runtime-2.0</artifactId>
            <version>${gmaven-plugin.version}</version>
            <exclusions>
                <exclusion>
                    <groupid>org.codehaus.groovy</groupId>
                    <artifactid>groovy-all</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupid>org.codehaus.groovy</groupId>
            <artifactid>groovy-all</artifactId>
            <version>${groovy.version}</version>
        </dependency>
    </dependencies>
</plugin>

With these configuration we can use spock and write our first specifications. But there is one issue: default settings for maven-surefire plugin demand that test classes must end with "..Test" postfix, which is ok when we want to use such naming scheme for our spock tests. But if we want to name them like CommentSpec.groovy or whatever with "..Spec" ending (what in my opinion is much more readable) we need to make little change in surefire plugin configuration:

<plugin>
    <groupid>org.apache.maven.plugins</groupId>
    <artifactid>maven-surefire-plugin</artifactId>
    <version>2.15</version>
    <configuration>
        <includes>
            <include>**/*Test.java</include>
            <include>**/*Spec.java</include>
        </includes>
    </configuration>
</plugin>

As you can see there is a little trick ;) We add include directive for standard Java JUnit test ending with "..Test" postfix, but there is also an entry for spock test ending with "..Spec". And there is a trick: we must write "**/*Spec.java", not "**/*Spec.groovy", otherwise Maven will not run spock tests (which is strange and I've spent some time to figure out why Maven can't run my specs).

Little update: instead of "*.java" postfix for both types of tests we can write "*.class" what is in my opinion more readable and clean:

<include>**/*Test.class</include>
<include>**/*Spec.class</include>

(thanks to Tomek Pęksa for pointing this out!)

With such configuration, we can write either traditional JUnit test and put them in src/test/java directory or groovy spock specifications and place them in src/test/groovy. And both will work together just fine :) In one of my next posts I'll write something about using spock and its mocking abilities in practice, so stay in tune.

DDevelopment & Design