Dopar

Hallo Leute,

folgendes kleines Problem wo ich von euch vielleicht kurz ein paar Tipps oder gute Google Schlagwörter / Tutorial Links brauchen könnte:


Ich habe einen FlashClienten auf Adobe Air(2.6) der beim Starten einen Request an das PHP Script auf meinem Server schickt und sich somit "am Server anmeldet". Der Server weiß nun wie viele bzw. welche Clients am System angemeldet sind und soll entsprechend von Informationen die er in unregelmäßigen Abständen erhält einige Daten an einen der angemeldeten Clients schicken.

Ich hatte darüber nachgedacht das der Client einfach in regelmäßigen Abständen am Server fragt ob neue Informationen bereit stehen. Das Problem ist das mir das auf Dauer zu viel Traffic verursacht. Es kann öfter vorkommen das am Tag nur 1 oder 2 mal Daten zur Verfügung stehen und wenn ich das dann alle 10 Sekunden abfrage ist das sinnlose Auslastung.

Die Abstände vergrößern kann ich leider auch nicht, weil wenn neue Daten zur Verfügung stehen diese mit einer maximalen Verzögerung von 10 Sekunden beim Client angekommen sein sollten.

Kann mir jemand Ideen geben wie man so einen Aufruf vom Server aus an den FlashClient steuert?

Den Rest hab ich soweit hin bekommen.

Danke im vorraus.

Mister Ad

tr0y

also bei ~10 Byte responses wäre das pro user pro monat 2,5 Megabyte "antwort"-traffic vom Server, wenn man davon ausginge das der Server bei dem User 24 h / 7 Tage die Woche / 365 Tage im Jahr antworten muss, was wohl nie zutreffen wird.. Ich schätze du hast dich etwas bei deiner "zu hoher Traffic"-Berechnung verkalkuliert, oder du hast soviel User das du mehrere Petabyte Traffik damit erzeugen würdest..

Missversteh mich nicht, du musst nur zurückgeben ob neue nachrichten da oder nicht, keine Lebensgeschichte, die kann dann "erneut" requested werden, wenn sie denn was neues wär'. Du bräuchtest vermutlich nur nen Timestamp durch die "Welt" antworten..

Vielleicht erläuterst du ja was dein Client genau macht, damit man in etwa abwegen kann, welche Response / Request Mechnik bei dir ratsam wär'.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

Dopar

Okey ich geb' zu so mathematisch bin ich da nicht ran gegangen.


Es geht darum das das System bei einem Kunden laufen soll der immer "sofort" die Nachricht im Air Clienten haben möchte sobald er nen neuen Comment in seinem Ticket System bekommt. Das kann - wie gesagt - 5 mal pro Stunde sein, kann aber auch nur nur 2 mal pro Woche sein.

Bei jedem dieser Requests wird nur eine Anfrage an das PHP Script gegeben dem ca. 2 - 5 Parameter übermittelt werden und das Script gibt eine ganz simple Antwort - vermutlich in Form eines JSON Arrays die zurück geschickt werden muss.

Sollte die Anfrage "positiv" ausfallen, das heißt, dass ein neuer Eintrag vorhanden ist könnte die Menge der Daten doch durchaus erhöht werden, da die Comments durchaus umfang reich sind und u.U. mit Attachments verbunden sind.

Je nach dem wie erfolgreich das System ist soll der Client später noch um einen ChatClient erweitert werden, wo dann nichtmal die 10 Sekunden ausreichen würden. Daher war ich am Überlegen gleich auf eine Server to Client Beziehung um zu stellen.

ChrisB

Conditional GET mit If-Modified-Since, Server mit 304 Not Modified antworten lassen, wenn's nix neues gibt, fertig.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

tr0y

@ChrisB: Jo sowas der art.

@Dopar: Trotz dem Chat, wird es nicht viel Traffic beanspruchen Zustands-Requests durchzuführen. Die schlussendlich auch der Chat nutzen kann um "neue Chatlines" abzufragen. ( Wobei ich bei chats auch bei medium systemen eher auf existierende deamon-technologie die in jede dimension skallierbar ist - IRCd - zurückgreifen würde )

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

php1704

Also mit 10 Bytes pro Requests ist es ja bei weitem nicht getan. Selbst wenn eine "leere" Antwort kommt.

Wenn du eine HTTP-Anfrage schickst kommen da (inkl. Antwort) schonmal locker 200 Byte nur an Header-Daten zusammen.

Sowas kannst du mit TCP-Sockets machen.
Von Flash aus kannst du ja mit Sockets arbeiten.
Auf Serverseite brauchst du dann ein Server-Programm/Skript, dass die Verbindungen der Clients entgegen nimmt und ihnen dann die Daten zukommen lässt.

Google mal nach:
server push
tcp socket server

Grüße.

tr0y

selbst 200 bytes sind nix..

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

php1704

Auch Kleinvieh macht Mist

Grüße.

lstegelitz

Wozu soviel Arbeit? Aktives Polling, einfach ein Button oder Link mit "jetzt nach neuen Daten suchen", klicken, checken, fertig. Wenn ich es richtig verstanden habe, ist es kein Chat, und bei Intervallen von 2 mal pro Woche (im schlechtesten Fall) ist jedes regelmässige Polling überdimensioniert.

__________________
Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

Griffith

Auch der Verbindungsaufbau über TCP braucht Traffic und Zeit,
und das selbst bei ner Payload von 0 Bytes.

Ist halt die Frage welcher Traffic genau berechnet wird:
Ethernet? TCP Payload? HTTP Payload?

Das Hauptproblem ist eigtl auch, dass der Server von außen aus keine TCP-Verbindung zum Client herstellen kann, wenn der Client hinter einem NAT hockt.
Über NAT kann eine Verbindung nur hergestellt werden, wenn der Client sie initiert.
Der Client muss also immer regelmäßig eine Verbindung eröffnen und/oder möglichst lange offen halten.

Wenn die Verbindung einmal offen ist, kann man die Verbindung offen halten und auf eine Antwort vom Server warten.
Nennt sich dann Long Polling.

Long Polling ist verglichen mit "normalen" Polling sinnvoller, weil...
1. Traffic-schonender (TCP-Payload bleibt bei 0; Overhead für die TCP-Payload ist natürlich weiterhin vorhanden: Ethernet und TCP/IP-Header)
2. Kürzere Antwortzeiten, da die Verbindung bereits aufgebaut wurde und die Antwort vom Server praktisch direkt kommt, ohne dass man nen 10 Sekunden Intervall hat.

http://en.wikipedia.org/wiki/Push_te...y#Long_polling