Kommunikation mit Mobil-Telefon

[Assarbad]

Moin.

Zitat von fkerber:

Die Frage, die sich mir nun stellt, ist, wie kann ich vom Server aus, quasi "ungefragt" Informationen an die Handys "pushen".

Indem du eine einfache TCP-Verbindung von der Serverseite aus aufbaust. Allerdings wird das vermutlich relativ unpraktikabel sein, wg. allerlei Unwägbarkeiten (Proxies sind nur eine Variante).

Warum also nicht den anderen Weg gehen und das Handy einfach anweisen alle X sec beim Server nachzufragen ob was "neues" da ist was gezogen werden soll?

Wenn du es clever anstellst, könnte die Abfrage einer statischen Datei gelten die eine Seriennummer (ähnlich wie die bei DNS-Records) enthält. So kann der Client anhand der Seriennummer die er kennt einschätzen ob er sich an das aufwendigere CGI-Skript (oder was immer du benutzt) wenden soll. Damit sparst du eine Menge Rechenzeit und auch Bandbreite.

Nachtrag: die meisten Aktualisierungsdienste funktionieren so, daß der Client die Verbindung initiiert.

[mkinzler]

Zitat:

Nachtrag: die meisten Aktualisierungsdienste funktionieren so, daß der Client die Verbindung initiiert.

Anders wird es auch nicht gehen. Wie gesagt würde ich eine Web-UI (HTML 5/CSS/JS/AJAX) basteln

[fkerber]

Hi,

Zitat von Assarbad:

Indem du eine einfache TCP-Verbindung von der Serverseite aus aufbaust. Allerdings wird das vermutlich relativ unpraktikabel sein, wg. allerlei Unwägbarkeiten (Proxies sind nur eine Variante).

Von was für Unwägbarkeiten sprichst du denn da?
Wo spielen z.B. Proxies eine Rolle oder könnten ein Problem darstellen?


Liebe Grüße,
Frederic

[Assarbad]

Zitat von fkerber:

Von was für Unwägbarkeiten sprichst du denn da?
Wo spielen z.B. Proxies eine Rolle oder könnten ein Problem darstellen?

Wenn du von deinem Server aus eine Verbindung aufbauen willst und diese nicht vom Client käme, wie willst du bspw. hinter einen Zwangsproxy des Zugangsproviders oder in das NAT eines Routers dringen? Geht nicht - ergo: unpraktikabel.

[fkerber]

Hi,

ist das auch ein Problem, wenn der Client die Verbindung aufbaut?
Also der Plan an sich ist:

Die Handy-App kennt die Server-Daten und initiiert einen Login-Vorgang. Dazu wird eine Socket-Connection aufgebaut. Der Server weiß ja dann, von wo (IP) die Anfrage kommt und kann dann dahin was zurückschicken.

Das haben wir PC<->"Server" (allerdings alle im selben lokalen Netz) schon erfolgreich umgesetzt.

Wären die Umstände hier so anders?


Liebe Grüße,
Frederic

[Assarbad]

Zitat von fkerber:

ist das auch ein Problem, wenn der Client die Verbindung aufbaut?

Nein, dann wäre es kein Problem.

Zitat von fkerber:

Die Handy-App kennt die Server-Daten und initiiert einen Login-Vorgang. Dazu wird eine Socket-Connection aufgebaut. Der Server weiß ja dann, von wo (IP) die Anfrage kommt und kann dann dahin was zurückschicken.

Das haben wir PC<->"Server" (allerdings alle im selben lokalen Netz) schon erfolgreich umgesetzt.

Wären die Umstände hier so anders?

Ich merke hier hapert es bei Begrifflichkeiten. Klar kann der Server was zurückschicken, wenn der Client es anfragt. Aber was der Server eben in vielen Fällen nicht wirklich kann (ansonsten reden wir quasi über einen zweispurigen Tunnel) ist selber eine Verbindung zum Client aufzubauen.

Und dann wäre hier ohnehin noch die Frage ob (und wenn ja warum) die Verbindung persistent sein soll.

Prinzipiell würde es wohl reichen wenn der Client sich in Intervallen an den Server wendet. Von dort bekommt er bspw. die Info (statisch): ja, es liegt eine Aktualisierung vor. Dann - unter der Annahme daß du beide Seiten entwickelst - kann der Client sich doch an eine andere URI auf dem gleichen Server wenden und bspw. authentifizieren und dann bei nachgewiesener Berechtigung die Aktualisierung runterladen. Aber in allen genannten Fällen würde die Initiierung der Verbindung immer durch den Server stattfinden.

[fkerber]

Hi,

ja, vllt. reden wir wirklich etwas aneinander vorbei.
Also ganz am Anfang wird der Client sich einmalig beim Server melden und sagen "hier bin ich".

Dann wäre die Idee, die Verbindung aufrecht zu halten und bei Bedarf (es gab eine Aktualisierung der Daten auf dem Server, z.B. durch anderes Handy) den offenen Kanal zu nutzen, um diese Info an das Handy zu übertragen.

So hatten wir es bei dem anderen Projekt gelöst (allerdings PCs statt Handys und alles nur lokales Netz).


Daher war die Frage:
Kann ich das quasi 1:1 umsetzen oder ist das vllt. nicht so klug?

Ein Problem sah ich schon bei evtl. Internet-Verbindungs-Abbrüchen auf Handy-Seite.


Wäre deiner/eurer Meinung nach die folgende Variante besser:
Handy fragt alle x (x = ~10s) den Server an und bekommt alle relevanten Infos zurück. D.h. der Server würde immer nur antworten und niemals selbst initiiert etwas senden (unabhängig davon, wer den Verbindungsweg geöffnet hat).


Liebe Grüße,
Frederic

[Assarbad]

Zitat von fkerber:

ja, vllt. reden wir wirklich etwas aneinander vorbei.

Denkbar.

Zitat von fkerber:

Also ganz am Anfang wird der Client sich einmalig beim Server melden und sagen "hier bin ich".

Dann wäre die Idee, die Verbindung aufrecht zu halten [...]

Wieviele Clients erwartest du? IPv4 oder IPv6? Bei IPv4 wirst du schnell an Grenzen bzgl. Sockets/Ports stossen.

[FBrust]

Hallo,

bei "ungefragt" fällt mir nur die Möglichkeit ein, den Handys eine SMS zu schicken, die wiederum die Android-Applikation veranlasst, eine Verbindung zum Server zu etablieren. Frag mich aber nicht, wie das geht, hab nur gelesen, dass sowas möglch ist (hab erst mit Android-Programmierung angefangen )


Grüße
Frank