Entwerfen eines Netzwerkprotokolls für Echtzeitdaten / mobile Geräte

8

Ich stehe vor einem folgenden Dilemma:

Entwerfen Sie ein neues Netzwerkprotokoll, das zwischen einem Server (Java-Software) und Desktop- und mobilen Clients verwendet wird. Zu den mobilen Clients gehören J2ME, Android und vielleicht in Zukunft sogar das iPhone.

Der Datenstrom ist ein Echtzeit-Konstantstrom mit auch selteneren Teilen. Die Clients zeigen Wellenformen dieser Daten und auch Daten, die nicht sofort aktualisiert werden müssen. Die Clients sollten ebenfalls authentifiziert sein.

Ich möchte es vermeiden, wenn möglich eine vollständig benutzerdefinierte TCP-Protokollimplementierung von Grund auf zu erstellen.

Heutzutage empfehlen die Leute normalerweise, alles im REST-Stil zu machen, was ich auch wirklich mag. In diesem Fall bin ich jedoch ein wenig zögerlich: Wie würden Sie einen konstanten Datenstrom zusätzlich zu REST implementieren? Eine chunked HTTP-Antwort?

Ich denke auch über Nicht-Klartext-Protokolle nach (die aktuellen, die ich ersetze, sind binäre Protokolle). Diese aktuellen Protokolle haben ihre ernsthaften Probleme, so dass sie wirklich ersetzt werden sollten.

Google-Protokollpuffer sehen nach einem ziemlich starken Kandidaten für die Verarbeitung der Low-Level-Details aus, aber ich bin mir nicht sicher, ob es von Android aus verwendet werden kann. Und ich bin mir ziemlich sicher, dass die iPhone-Implementierung auch Probleme damit haben würde.

Es gibt auch BEEP , aber ich denke, es ist ziemlich tot und ich frage mich, ob es jemals weit verbreitet war.

Irgendwelche Ideen?

    
auramo 17.01.2010, 08:29
quelle

4 Antworten

8

Ich denke, bevor Sie in das Protokolldesign einsteigen, sollten Sie die folgenden Punkte wirklich sorgfältig beachten:

  • Fast alle Protokolle außer HTTP werden heutzutage von Firewalls gefiltert. Sogar viele Inhaltstypen und Ports (außer 80) können von Dienstanbietern gefiltert werden, insbesondere in mobilen Datendiensten. Stellen Sie daher sicher, dass Sie in Ihrem Zielnetzwerk keine Firewall-Probleme haben, bevor Sie ein Protokoll verwenden oder entwerfen.
  • Größe und Geschwindigkeit sind wichtig. Versuchen Sie, effiziente Protokolle sowohl für die Transportnachrichtengröße als auch für die Codierung / Decodierung (Serialisierung / Deserialisierung) zu verwenden. Google Protokollpuffer bietet eine zuverlässige Lösung für dieses Problem.
  • Verbindungen werden immer getrennt. Sie können sich nie darauf verlassen, dass eine Verbindung wegen NAT-Timeouts (standardmäßig 15 Minuten), Protokoll-Timeouts (30 Minuten für TCP) und vielen bestehenden Netzwerkproblemen lange offen bleibt. Also, bevorzugen Sie kein Protokoll gegenüber dem anderen, nur weil es die Verbindung offen hält (es kann versuchen, aber nie gelingt). Das Senden von Heartbeats ist ein guter Versuch für das Timeout-Problem, aber Netzwerk-Verbindungsunterbrechungen sind immer noch unvermeidbar.
  • Durchsatz ist wichtig. Unter Durchsatz verstehe ich die Anzahl der Nachrichten, die in einem Zeitraum (z. B. 1 Sekunde) verarbeitet werden. Die Verwendung von asynchronen Protokollen, die einen Client nach dem Empfang seiner Nachricht trennen, trägt wirklich zur Erhöhung des Durchsatzes bei. Obwohl Sie nicht darauf angewiesen sind, eine Verbindung zum Client vom Server herzustellen, um das Ergebnis zu pushen, da viele Clients hinter NATs und Firewalls stehen, die direkte Verbindungen von außen vermeiden. Versuchen Sie, die Verbindung offen zu lassen oder den Server nach dem Ergebnis abzufragen. Das Vermeiden von Status in einer Konversation ist auch die andere Methode, die dazu beiträgt, den Anwendungsdurchsatz zu skalieren, wenn die Anzahl der Clients zunimmt.
  • In vorhandenen WANs gibt es keine Echtzeit. Trauen Sie nicht denen, die sagen, dass sie ein Echtzeitprotokoll basierend auf bestehenden WAN-Protokollen implementiert haben. Sie können niemals ein Echtzeitprotokoll zusätzlich zu Nicht-Echtzeitprotokollen implementieren. Sie können einfach Ihr Bestes geben und dafür beten, dass das Netzwerk schnell geht. Das heißt: Hör nicht auf, tu dein Bestes.
  • Non-Blocking IO. NIO (Non-blocking IO) ist der Trend, der jetzt effektiv in der Netzwerkprogrammierung verwendet wird. Es ermöglicht eine große Anzahl von Verbindungen mit weniger Speicherauslastung und einer begrenzten Anzahl von Threads. Java 5 hat native Unterstützung für NIO, die sehr primitiv ist. Viele Frameworks wie Apache MINA und Netty , wurden basierend auf Java NIO implementiert, um die blockierungsfreie Programmierung einfacher und robuster zu machen. Ich empfehle sie dringend.
Amir Moghimi 17.01.2010 11:10
quelle
3

Sie können sich Kryo und / oder KryoNet , die NIO und Java-basiert sind und den Desktop und Android arbeiten. Sie müssten jedoch die iPhone-Seite schreiben, was ziemlich schwierig wäre. Kryo schlägt die Protokollpuffer von Google in serialisierter Größe ( Benchmarks hier ) und die Benutzerfreundlichkeit (Nr .proto-Typ-Schema muss geschrieben werden, mit Kryo sind die Java-Klassendefinitionen das Schema).

In Bezug auf NIO können Sie sich NPTL ansehen. Das Alte wird wieder neu.

    
NateS 17.01.2010 11:17
quelle
2

Sie können sich das RTP (Echtzeit-Transportprotokoll) ansehen, das möglicherweise nicht direkt nützlich ist (und / oder könnte übertrieben sein), aber sein Design würde Ihnen einige gute Ideen geben, um davon zu arbeiten. Und Sie könnten es vielleicht auch benutzen.

    
Michael Burr 17.01.2010 08:44
quelle
2

Es ist keine elegante Lösung, aber Sie können dies über "Straight http" tun, indem Sie das Feld "content-length" in der HTTP-Antwort nicht festlegen und den Ausgabestream nie schließen. Sende einfach weiter Daten.

Sie können auch eine sehr große Inhaltslänge festlegen und Daten vom Server in Echtzeit zurücksenden, bis der Server diesen Betrag gesendet hat. Dann kann der Client eine neue Anfrage erstellen oder nicht.

Leider konnte ich keine nützlichen Links für diese Ideen finden, aber ich vertraue darauf, dass Sie die Ideen bekommen.

Das eigentliche Plus dieser Ideen ist, dass sie über HTTP sind, was durch das Firewall-Problem kommt, und Sie können Ihre App als Webanwendung mit einem Servlet implementieren.

Nur meine 2 Cent;)

    
simonlord 17.01.2010 11:40
quelle

Tags und Links