AMF als String?

[mb0]

Einfach nur ne Frage:
Weiß jemand wie und wo AMF codiert bzw. decodiert wird?
Kann man den AMFcode von irgendeinem Objekt innerhalb von flash anzeigen ohne es zu senden?
Ihr fragt euch sicher wozu das gut sein sollte.
Ich würd einfach nur gern wissen wie das funktioniert mit AMF.
Ich hab schon NetServices durch geschaut, aber da wird auch nur NetConnection benutzt und ich checke einfach nicht wie Flash das macht bzw. wie man es benutzen könnte.
NetConnection.call ?? und fertig? Aber was passiert da ?
Hat irgendwer eine Idee?

[bokel]

Wie das Format genau aussieht, kannst du dir auf der Serverseite anschauen. Die Umwandlung passiert intern im Flashplayer, darauf hast du keinen Zugriff.

mfg r.

[mb0]

Ich hab letztens nur in der flashcoders mailing list ne frage zu xmlsocket mit amf daten gesehen... und hab mich gefragt wie der das wohl anstellen will.
is klar die komprimierung fällt weg. aber es würde schneller verarbeitet werden als xml. deshalb fand ich die idee ganz gut und wollte mal sehen was sich machen lässt.

War ja auch nur ne Idee. Schade drum.

Kann jemand das Thema löschen? Wird woll nicht mehr gebraucht...

[bokel]

Es ist wohl so, dass die Kommunikation des Flashplayers mit dem FlashCom-Server über AMF laueft. Leider ist das genaue Protokoll nicht bekannt. Zumindest noch nicht

Der XML-Socket eignet sich nicht zum Transport binärer Daten, weil das 0-Byte als Stop-Markierung benutzt wird.

mfg r.

[mb0]

Geschrieben von bokel
Der XML-Socket eignet sich nicht zum Transport binärer Daten, weil das 0-Byte als Stop-Markierung benutzt wird.

Check ich irgendwie nicht!
Das xmlsocket sich nicht eignet ist klar, überträgt ja als String.
Aber möglich müsste es doch sein, binäre Daten als String zu Übertragen und wider zu entschlüsseln. Klar die Kompression fällt weg (sagt ich bereits), da es eben als String übertragen wird.
Nullbyte ist doch nur das ende eines String (wie in C).

Aber was hat das miteinander zu tun?
Hab echt keine Ahnung; bitte, bitte sag es mir.

[bokel]

Ja, du muesstest dann deine Daten so verschluesseln, dass keine Nullbytes vorkommen.

mfg r.

[flory]

das schöne an Remoting ist neben dem binären AMF Format auch
die automatische Serialisierung. Das alles macht der Player selbst,
während man für XMLSocket Serialisierung und Datenkompression
in Actionscript realisieren müsste, was meiner Meinung nach
den Aufwand nicht lohnt. Was soll das ganze denn auch bringen?
Audio und Video wirst Du ohnehin über das XMLSocket nicht übertragen
können.
Zur Ursprungsfrage: wie bokel schon sagt, anschauen kannst
Du es nur während der Übertragung oder auf der Serverseite.
In Flash selbst hast Du keinen Zugriff auf die binären Daten.

[mb0]

Erstmal danke an bokel!
du hast es echt drauf hab schon viel von dir gelernt...
(auch wenn du es nicht weißt)..

xmlsocket ist einfach viel schneller!!!
ich muss komplexe Daten austauschen,
und amfphp braucht zu lange.
auf meiner testplatform z.B mit apache
~180ms.
mit eigenem sever
~90ms.
mit xmlsocket +wddx
~20ms.
doch ich dacht mir, dass bei größeren Datenstrukturen das mit dem Wddx langsamer wär als amf deswegen meine frage.
Ich wollte die vorteile beider ideen zusammen legen (versuchen).

Wenn ihr noch ne Idee habt was besser wär als wddx zum strukturieren von daten sagt mir umbedingt bescheid danke.

Datenkompression fällt mir spontan nur rle ein was bei wddx/xmlstrings nicht besonders viel bring rle2 wäre schon wieder viel zu aufwendig umzusetzen und auch nicht besonders logisch... wenn euch dazu noch was einfällt sagt es bitte!!

[bokel]

Ist ja echt merkwürdig. Ich hätte erwartet, dass Remoting schneller ist. Was für Strukturen sind das denn, mit denen du deinen Test machst ?

mfg r.

[mb0]

eine stehende verbindung ist natürlich schneller als ein http packet, da ja die verbindung nicht jedesmal neu aufgebaut werden muss (im millisekunden bereich merkt man das deutlich).
und mit nem apache ist es natürlich auch langsamer als mit einem super schlanken selfmade server der nicht anderes macht als die header abzucutten und die verarbeitung zu starten, da apache erstmal schaut was es ist ob es vollständig ist und so weiter.

Man muss dazu sagen das ich die test mit einfach strukturierten daten gemacht hab.

Außerdem sind das LAN zeiten im netz fällt das für die clients nicht so ins gewicht mit den deserialisierungen der Verbindungsaufbau wird aber um so wichtiger. Die Socket verbindung wird sehr viel schneller sein (z.B. dns-aufschlüsselung? telekom?bei jeder verbindung?)

sowas merkt man aber nur bei chats usw.
bei einer datenbank abfrage z.B. ******t man doch auf 200ms...

[bokel]

Ah, ich hatte ganz vergessen, dass wir XMLSocket mit Http vergleichen. Gut, die Unterschiede mal in harten Zahlen zu wissen.

Wie ist das eigentlich: TCP-Pakete haben ja immer eine gewisse Mindestgroesse, oder ? Ich bin auch kein Netzwerkexperte, aber ich habe irgendeine Zahl um 1500 Byte im Kopf. Wenn meine Daten inkl. WDDX-Verpackung in ein Paket passen, duerfte es eigentlich keinen Geschwindigkeitsunterschied geben. Stimmt das mit deinen Werten überein ?

mfg r.

[mb0]

geschwindigkeitsunterschied zu was?

zwischen http und stehender socket verbindung??

ich weiß nicht genau was du meinst...
wird beides über tcp abgefahren schon klar...
der entscheidende unterschied ist der verbindungaufbau!

Ich bin auch kein netzwerkexperte... aber stellen wir uns das als telephonat vor. beide seiten dürfen nur einen satz auf einmal sagen. da ist es trotzdem schneller abwechseln sätze zu sagen als jedes mal neu anzurufen...

ok ok das beispiel ist nicht besonders gut aber es macht doch sinn.
und auf die "harten werte" würde ich mich nicht verlassen das ist im lan mit meiner speziellen konfiguration so. und es sind grobe durchschnittswerte ich habe keine ahnung wie es zwischen einem hoch performanten schlundserver und dem dsl enduser aussieht.

[bokel]

Ich meinte den Unterschied zwischen Wddx-Verpackung und den einfachen Daten.

mfg r.

[mb0]

ja.

...hab echt nicht gecheckt was du meinst.

Danke für deine Hilfe!

[Gope]

Hallo,

Ein Ethernet-Frame (Paket) hat zwischen 46 und 1500 Byte an Daten das stimmt. Der Rest ist eher zu vernachlässigen. Allerdings ist wirklich di eVerbindungsart entscheidend. HTTP ist halt verbindungslos und Sockets haben konstante Verbindungen.

Hierdurch lässt sich bei Sockets das ständige Anfordern von Daten (Request) vermeiden. Somit sind socketorientiere Verfahren meistens schneller...

Ich bin aber auch sehr an den Performanceergebnissen interessiert, also postet ruhig weiter, wenn Ihr da noch mehr testet...

Gruß
Gope