Netzwerkprogrammierung: PUSH Service Programmieren

[errox]

Hallo.

Zur zeit arbeite ich Produktiv mit einem TomTom Gerät (TomTom Work, Webfleet wenn es jemanden was sagt)

Jedenfalls bin ich erstaunt wie man Nachrichten übermitteln kann. Schneller als SMS. In einem Portal Drückt man auf Senden, max. 1 Sekunde dauert es bis die Nachricht am TomTom Gerät ankommt.

Diese Technik will ich auch für eine private Chatanwendung verwenden. Ich habe bereits erfahrung mit der Netzwerkprogrammierung (Sockets, TCP/IP Verbindungen, Datenaustauschen). Im Internet steht viel von einem PUSH Service, dass der Server OHNE Anfrage vom Client die Daten direkt erhält.

Meine aktuelle Programmierlogik ist vergleichbar mit einem e-Mail Hoster. In einem Intervall von n-Sekunden wird überprüft, ob sich Daten im Buffer befinden. Wenn ja, werden diese Ausgelesen. Vergleich: Ich überprüfe alle n-Sekunden / Minuten ob ich eine neue e-Mail habe.

Leider habe ich zur Zeit keinen Ansatz, wie ich so einen PUSH Service Programmieren kann, woher soll der Wissen dass die Daten da sind oder welche gekommen sind ohne zu Überprüfen? Oder ist das alles nur ein "Mythos"? Ich weiss leider nicht wie das die SMS macht, ein Anruf oder der TomTom Webservice. Ein Handy oder ein Telefon Kontrolliert sicherlich nicht jede Sekunde "Ruft mich jemand an? Ja? -> Telefon Klingeln lassen"

Wenn mir jemand einen Ansatz geben kann, wäre das Super. Seid einigen Wochen mache ich mir gedanken wie man so etwas Umsetzen kann.

Danke!

P.S. Ich programmiere in C# .NET

Gruß errox

[BlackDragon83m]

Hallo auch,

du könntest deinen Webservice wie folgt aufbauen bzw. den Push so anstoßen:

Bei einem Chat hast du ja 1x Server und XY x Clients. Sagen wir also 1x Server und 3 Clients.

Nun schickt Client 1 eine Nachricht an den Server -> Dieser lauscht auf einem Webservice / Port / oder ähnlichem ob einer seiner Clients ihm etwas schickt. Ist dies der Fall so wird die Meldung weiterverarbeitet (sofern nötig z.B. in DB speichern) und dann sendet der Server die eingegangene Nachricht an alle Clients.

Die Clients wiederum haben - wenn man so will 2 Service laufen: 1x einen zum senden > wird z.b. per Enter / Button / etc. getriggert und schickt die Daten wie oben beschrieben zum Server.

Der andere Thread / Client ist eine art Endlosschleife, welche darauf wartet ob der Server etwas schickt -> Ist dies der Fall werden die empfangenen Daten verarbeitet.

Also 2 Seitiges Konstrukt auf beiden Seiten:

Server:

* Webservice lauscht ob einer der Clients etwas schickt und verarbeitet dies UND sendet die Daten an alle Clients

Client:

* Sendet durch speziellen Trigger (z.B. Button) seine Daten an den Server und lauscht unentwegt ob von dort Daten kommen.

Nun kann man das ganze natürlich noch verfeinern um z.B.:

* Den Server die Daten überprüfen zu lassen bevor sie gesendet werden

* Den Server die neuen daten mit den alten Daten vergleichen lassen und nur Änderungen / Neuerungen versenden lassen

* Die Clients nur auf spezielle Änderungen reagieren lassen

Gruß Thomas

[errox]

Hallo auch,

Die Clients wiederum haben - wenn man so will 2 Service laufen: 1x einen zum senden > wird z.b. per Enter / Button / etc. getriggert und schickt die Daten wie oben beschrieben zum Server.

Der andere Thread / Client ist eine art Endlosschleife, welche darauf wartet ob der Server etwas schickt -> Ist dies der Fall werden die empfangenen Daten verarbeitet.

Hallo. Ich habe es bereits so laufen. Das läuft soweit ganz gut.

Ich dachte aber, dass es eine andere Technologie dahinter steckt, die "anders" funktioniert.

Weil vergleichbar macht ja der Client nichts anderes als (Hab ich neue Daten? (z.B. e-Mails), Hab ich neue Daten?, Hab ich neue Daten?, ...)

Blos halt in einem kürzerem Zeitintervall (1 ms nicht 0, damit die CPU nicht überlastet wird)

Wenn der PUSH Service wirklich so funktioniert, dann hab ich es ja bereits auch. Ich kontrollier in meiner Schleife blos, ob neue Daten da sind (NetStream.DataAvailable -> C#)

Ich dachte dahinter steckt eine spezielle Technologie dahinter. Aber was solls (:

Trozdem danke!

Gruß errox

[smash]

Push-Dienst ? Wikipedia

Ich denke, dass Pushdienste nach dem Publish & Subscribe-Prinzip arbeiten. In deinem Fall melden sich die Chatclients am Server an. Dieser merkt sich z.B. die IP-Adresse der Clients, damit er sie später erreichen kann. Die Chatclients können Nachrichten an den Server schicken. Immer wenn der Server eine neue Nachricht empfängt schickt er sie an alle angemeldeten Clients weiter. Wenn ein Client keine Nachrichten mehr empfangen soll, sollte er sich beim Server abmelden. Der Server löscht dann die IP-Adresse.

Der Clou ist, dass der Client eben nicht immer erst eine Anfrage an den Server schicken muss, wenn er wissen will, ob neue Nachrichten verfügbar sind. Wenn ein Client immer auf dem neuesten Stand sein soll, müsste man diese Anfragen eben regelmäßig schicken (Polling auf Anwendungsebene). Beim Publish & Subscribe-Verfahren ist stattdessen nur die An- bzw. Abmeldung erforderlich.

Es handelt sich dabei um ein ganz allgemeines Verfahren, dass natürlich mit verschieden Technologien umgesetzt werden kann. Wenn du es über TCP/IP Netze umsetzen willst, musst du die Netzwerkkommunikation entsprechend implementieren. Du musst z.B. in Erfahrung bringen, ob an deiner Netzwerkschnittstelle neue Nachrichten eingetroffen sind. Dies kannst du wieder mit Polling machen. Dies ist nicht spezifisch für P & S. Dieses Polling findet auf einer unteren Ebene und nicht auf Anwendungsebene statt. Dieses Polling wird nur innerhalb des lokalen Systems ausgeführt. Es werden dabei keine Nachrichten zwischen Client und Server ausgetauscht, sondern nur zwischen deiner Anwendung und der Netzwerkschnittstelle bzw. dem Betriebssystem.

Bearbeitet 7. Juni 2010 von smash

[errox]

Ja aber woher will der Client wissen dass neue Nachrichten da sind? Wenn das wirklich nur ein assynchroner Vorgang durch einen Thread ist der im Hintergrund guckt ob Daten da sind hab ich das bereits implementiert.

Wieso sollte der Client fragen "Hab ich neue Daten?". Der ließt doch eh das, was im Buffer steht. (C# .NET, ich weiss nicht wie es in anderen Programmiersprachen ist)

Weil ich hab mir eine andere Algorythmik vorgestellt die keinen Traffic verursacht.

[smash]

Ja aber woher will der Client wissen dass neue Nachrichten da sind? Wenn das wirklich nur ein assynchroner Vorgang durch einen Thread ist der im Hintergrund guckt ob Daten da sind hab ich das bereits implementiert.

Ich denke wir müssen ein bisschen aufpassen, dass wir nicht aneinander vorbei schreiben . Vielleicht habe ich mich ja auch unklar ausgedrückt.

Der Client weiß das eine neue Nachricht da ist, weil sie bei im ankommt. Das kann man mit dem Briefverkehr der Post vergleichen.

Stell dir vor es gibt eine Person S (=Chatserver). S hat hin und wieder neue Informationen, die für dich interessant sind. Du könntest also regelmäßig einen Brief an S schicken (=Netzwerkverkehr) und fragen ob neue Informationen verfügbar sind. Das ist Polling.

Alternativ kannst du einen Brief an S schicken (=Subscribe) mit dem Inhalt: "Hallo S, schick mir doch bitte immer die neuesten Informationen zu". S merkt sich dann deine Adresse und schickt dir immer einen Brief, wenn neue Informationen verfügbar sind (=Publish).

Du musst also keinen Brief mehr verschicken, um zu erfahren, ob neue Informationen verfügbar sind. Stattdessen schaust du einfach regelmäßig (=Polling) in deinen Briefkasten (=Netzwerkschnittstelle).

Wieso sollte der Client fragen "Hab ich neue Daten?". Der ließt doch eh das, was im Buffer steht. (C# .NET, ich weiss nicht wie es in anderen Programmiersprachen ist)

Also ich kenne mich jetzt nicht besonders gut mit der Programmierung von Sockets aus. Wenn ich mich richtig erinnere, schreibt man doch eine Endlosschleife, die immer wieder die Netzwerkschnittstelle abfragt (=Polling bzw. das Nachschauen im Briefkasten). Wenn es da eine andere Variante gibt, würde mich das auch interessieren. Kann man vielleicht direkt vom OS benachrichtigt werden oder so. Ich denke, dass das Programm zumindest wieder CPU Zeit bekommt, wenn auf dem entsprechenden Port etwas vorliegt.

Weil ich hab mir eine andere Algorythmik vorgestellt die keinen Traffic verursacht.

Die oben beschriebene Lösung verursacht nur Traffic bei:

1. Den Nutzdaten, die wohl in jedem Fall übertragen werden müssten.
   
2. Anmeldung
   
3. Abmeldung
   

Der Traffic ist also u. U. relativ gering. Das Nachschauen im Briefkasten verursacht ja keinen Traffic im Netzwerk.

Manchmal gibt es aber auch gute Gründe auf Polling zu setzten, z. B. bei Embedded- und Echtzeitsystemen. Nach dem selben Prinzip funktionieren auch Newsletter und viele andere Vorgänge.

Alles klar?

[errox]

Wenn ich mich richtig erinnere, schreibt man doch eine Endlosschleife, die immer wieder die Netzwerkschnittstelle abfragt (=Polling bzw. das Nachschauen im Briefkasten). Wenn es da eine andere Variante gibt, würde mich das auch interessieren.

Genau das mein ich

Meine Aktuelle Netzwerkimplementation sieht so aus, dass der Server 3 Threads hat. Eine zum Senden der Nachrichten, zum Empfangen und für neue Benutzer, die sich "Anmelden".

Client 2 Threads: Senden und Empfangen.

Beim Thread beim Server der neue Clients Empfängt (TcpClient AcceptTcpClient () ) anhält. Ich weiss nicht was er da Intern macht aber er macht erst weiter wenn einer Kommt.

Das muss doch auch beim Empfangen von Daten gehen ohne dass ich von mir aus einen Thread habe der Assynchron überprüft ob Daten da sind ("Sind daten da, sind daten da") Sondern ein anderes Verfahren dass den Thread anhält bzw erst weiter macht, wenn Daten da sind.

Hoffentlich versteht ihr worauf ich hinaus will. Ich hab ja auch keine Methode geschrieben "Neuer client? Neuer client, neuer client...." Sondern. "Ich wart einfach mal bis ein neuer client sich verbinden will" Und das macht der Intern bestimmt anders als eine Endlosschleife zu haben um zu kontrollieren "Neuer client, ..."

Ich weiss nicht ob man das bei den Sockets vergleicht: Aber wenn ich Post bekomme, weiss ich es daran dass sich einmal mein Brief schlitzt geöffnet hat damit die Post rein kommt, nicht daran dass ich am anderen Ende des "Briefkastens" darauf warte bis ein Brief drin ist.

Gruß

[smash]

Ich weiss nicht ob man das bei den Sockets vergleicht: Aber wenn ich Post bekomme, weiss ich es daran dass sich einmal mein Brief schlitzt geöffnet hat damit die Post rein kommt, nicht daran dass ich am anderen Ende des "Briefkastens" darauf warte bis ein Brief drin ist.

Wenn du abends nach Hause kommst, woher weißt du dann, das sich der Schlitz des Briefkastens geöffnet hat? Bei einem üblichen Deutschen Briefkasten siehst kannst du das nicht erkennen. Also musst du nachsehen ob Post da ist.

Du solltest dich mal intensiver mit Socketprogrammierung auseinandersetzen. Dann wirst du auch herausfinden, ob es da eine Alternative zum Polling gibt. Ich habe kurz mal bei Java geschaut. Da hat die Klasse ServerSocket eine Methode accept(), die wie folgt beschrieben wird:

Listens for a connection to be made to this socket and accepts it. The method blocks until a connection is made.

Vielleicht ist das das Richtige und vielleicht gibt es so etwas auch unter .Net. Außerdem würde ich bei einer Endlosschleife den Thread immer warten lassen, wenn gerade nicht vorliegt. Denn die Resource, die bei dieser Endlosschleife verwendet wird ist die CPU-Zeit und nicht die Netzwerkkapazitäten.

P.S.

Du kannst auch RPC machen anstatt dich selber mit Sockets herumzuschlagen. Bei Java gibts da schon was fertiges. Vielleicht gibt es da auch etwas bei .Net.

Bearbeitet 9. Juni 2010 von smash