MCOP protokolspecifikation

Den har begrebsmæssige ligheder med CORBA, men er beregnet til at kunne udvides på alle måder som kræves for multimediaoperationer i realtid.

Den sørger for en multimediaobjektmodel, som både kan bruges til kommunikation mellem komponenter i et adresserum (en proces), og mellem komponenter som findes i forskellige tråde, processer eller på forskellige værtsmaskiner.

Totalt set, vil den blive konstrueret til ekstremt høj ydelse (så alt skal optimeres for at være voldsomt hurtigt), passende for meget kommunikationsintensive multimedieprogrammer. At for eksempel sende video rundt er en af tilpasningerne for MCOP, hvor de fleste CORBA-implementationer ville gå i knæ.

Grænsefladedefinitionerne kan håndtere følgende selv:

og de vigtigste CORBA-kneb, såsom

Konstruktionsmål/idéer:

Kodningen af de forskellige typer vises i tabellen nedenfor:

struct test {
    string name;        // som er "hello"
    long value;         // som er 10001025  (0x989a81)
};

Hvis du har brug for at henvise til en type, angives alle primitive typer med navnene som findes ovenfor. Strukturer og nummereringstyper får deres egne navne (som Header). Sekvenser benævnes som *normal type, så en sekvens af long er “*long” og en sekvens af Header struct'er er “*Header”.

Formatet på MCOP's meddelelseshovede defineres af denne struktur:

struct Header {
    long magic;          // værdien 0x4d434f50, som kodes som MCOP
    long messageLength;
    long messageType;
};

De mulige meddelelsetyper er for øjeblikket

mcopServerHello                = 1
 mcopClientHello                = 2
 mcopAuthAccept                        = 3
 mcopInvocation                        = 4
 mcopReturn                                = 5
 mcopOnewayInvocation   = 6

Lidt information om MCOP's meddelelseshåndtering:

Meddelelseslængden i hovedet er naturligvis sommetider redundant, hvilket gør at metoden ikke altid er minimal med hensyn til antal byte.

Dette giver dog en enkel (og hurtig) implementation for behandling af meddelelser som ikke blokerer. Ved hjælp af hovedet kan meddelelser modtages af protokolhåndteringsklasser i baggrunden (uden blokering), hvis der er mange forbindelser til serveren kan alle behandles parallelt. Man behøver ikke kigge på meddelelsens indhold for at tage imod en meddelelse (og afgøre når man er klar), kun på hovedet, så koden for dette er ganske enkel.

Når en meddelelse er på plads, kan den afkodes og behandles i et enkelt skridt, uden at bryde sig om tilfælde hvor al data måske ikke er modtaget (eftersom meddelelseslængden garanterer at alt er på plads).

For at kalde en fjernmetode, skal man sende følgende struktur i en MCOP-meddelelse med messageType = 1 (mcopInvocation):

struct Invocation {
    long objectID;
    long methodID;
    long requestID;
};

derefter sendes parametrene som en struktur, f.eks. hvis man kalder metoden "string concat(string s1, string s2)", sendes strukturen

struct InvocationBody {
    string s1;
    string s2;
};

hvis metoden deklareredes som envejs, hvilket betyder asynkront uden returværdi, er det alt. Ellers får man en meddelelse som svar med messageType = 2 (mcopReturn).

struct ReturnCode {
    long requestID;
    <resulttype> result;
};

hvor <resulttype> er typen for resultatet. Eftersom void-typer udelades ved kodning, kan man også kun angive requestID hvis man returnerer fra en void-metode.

Så vor "string concat(string s1, string s2)" ville give en returkode som

struct ReturnCode {
    long   requestID;
    string result;
};

For at lave kald, skal man kende til metoderne som et objekt understøtter. For at gøre dette, er methodID 0, 1, 2 og 3 hårdkodede for visse funktioner. Det vil sige

long _lookupMethod(MethodDef methodDef);                                // metode-id altid 0
string _interfaceName();                                                                // metod-id altid 1
InterfaceDef _queryInterface(string name);                                // metodie-id altid 2
TypeDef _queryType(string name);                                                // metodie-id altid 3

for at læse dette, behøver du naturligvis også

struct MethodDef {
        string  methodName;
        string  type;
        long    flags;        // nu sat til 0 (kræves for strømme)
        sequence<ParamDef> signature;
};

struct ParamDef {
        string name;
        long   typeCode;
};

parameterfeltet indeholder typekomponenter som angiver typerne for parametrene. Typen for returkoden angives i typefeltet for MethodDef.

Hvis man skal være streng, er det kun metoderne _lookupMethod() og _interfaceName() som varierer fra objekt til objekt, mens _queryInterface() og _queryType() altid er ens.

Hvad er en sådan her methodID? Hvis man laver et MCOP-kald, forventes man at sende nummeret for metoden som kaldes. Årsagen til dette er at numre kan behandles meget hurtigere end strenge når en MCOP-forespørgsel køres.

Så hvordan skaffer man sig et sådan nummer? Hvis man kender til signaturen for metoden, dvs. en MethodDef som beskriver den (som indeholder navn, type, parameternavn, parametertyper og lignende), så kan man sende den til _lookupMethod for objektet hvor man vil kalde en metode. Eftersom _lookupMethod er hårdkodet til methodID 0, skulle det ikke være nogen problem at gøre dette.

Hvis man på den anden side ikke kender til metodens signatur, kan man finde hvilke metoder der understøttes ved at bruge _interfaceName, _queryInterface og _queryType.

Brugerdefinerede datatyper beskrives med strukturen TypeDef:

struct TypeComponent {
        string type;
        string name;
};

struct TypeDef {
        string name;

        sequence<TypeComponent> contents;
};