1. Zuhause
  2. Frage und Antwort
  3. Cross-Plattform-Echtzeit-Daten

Cross-Plattform-Echtzeit-Daten

2011-01-05 12 views
0

Ich arbeite an dem Entwerfen einer neuen Plattform für eine bestimmte Art von Anwendung. Diese Anwendungen werden hauptsächlich auf iOS- und Android-Geräten verfügbar sein. Eine der Hauptanforderungen in diesen Anwendungen besteht darin, dass Echtzeitdaten synchronisiert und sicher sind. Mein Gedanke ging direkt zu einer Art von Warteschlangenprotokoll mit Sockets. Die Einschränkungen auf dem Server sind, dass es in Java oder PHP geschrieben werden muss. Die Clients sind jedoch nicht eingeschränkt. Wie ich schon erwähnte, hauptsächlich iOS (Objective-C) und Android (Java) Geräte.Cross-Plattform-Echtzeit-Daten

Sollte ich etwas wie ActiveMQ oder Tibco implementieren, oder sollten andere Lösungen besser verwendet werden?

Mit freundlichen Grüßen,
Paul Peelen

Quelle

2011-01-05 Paul Peelen

+0

RSS über HTTPS und 10 Sekunden Timer? –

+0

Was meinst du mit Echtzeit? Was ist eine akzeptable Verzögerung? 10s, 1s, 100ms, 10ms, 1ms, 100us? –

+0

Zur Sicherheit: RSS oder jedes andere HTTP-Protokoll ist nicht vorzuziehen. Meiner Meinung nach ist eine Socket-Verbindung sicherer. Für die Verzögerung: 1-5s. Die Frage: Was ist die beste Lösung für den Transport von Echtzeitdaten zwischen dem Server und dem Gerät (beide Wege)? –

Antwort

1

Der beste Weg ist die Verwendung von RESTful API über HTTP. Leute, die sagen, dass Sockets sicherer sind als HTTP, verstehen normalerweise nicht, worüber sie sprechen (nichts Privates, Mann. Nur Geschäft!)

HTTP ist ein Transportprotokoll, das über TCP-Sockets funktioniert. Also, HTTP ist auch Sockets. Was Ihnen Sicherheit gibt, ist die Verschlüsselung dessen, was Sie senden. SSL ist die Antwort. Benutzer HTTPS, um Ihre Anwendung sicher zu machen.

Jetzt über Warteschlangen. Warteschlangen werden benötigt, um die Bereitstellung von Informationen und deren Verarbeitung zu entkoppeln. Dies ist in Ihrem Fall vorzuziehen, da die Verarbeitung Zeit braucht und Sie den Absender (mobiles Gerät) nicht blockieren möchten, während der Server die Daten verarbeitet. Ich würde vorschlagen, dass Sie Open-Source-Implementierung von Messaging-Broker (wie ActiveMQ, RabitQ, Qpid usw.) verwenden. Tibco ist perfekt, aber es kostet etwas Geld. Und wenn Sie in Richtung Java-Messaging-Broker gehen, implementieren Sie Ihren Server auch in Java und Benutzer-JMS-API, die von allen Messaging-Brokern unterstützt wird.

Ich hoffe, das hilft.

Quelle

2011-01-05 09:08:23 AlexR

+0

Vielen Dank für Ihre Antwort. Ich finde es sehr nützlich. Sie haben Recht mit dem HTTP-Zeug. Der einzige Gedanke, den ich von der Clientseite aus betrachte, ist, dass der Client (in der Theorie) den Verkehrssender von seinem Gerät hören kann und dadurch weiß, wie die API aussieht. Eine Socket-Implementierung kann dies besser verschlüsseln, glaube ich, richtig oder falsch?Das letzte, was ich möchte, ist, dass die Leute herausfinden, wie die API funktioniert, und mir Dummy-Daten schicken, die zu falschen Daten führen. –

+0

(1) Sie (und ich und jeder andere) können Daten nicht besser verschlüsseln als SSL; (2) Hacker können alles hacken, einschließlich Ihres proprietären Protokolls. REST ist Standard und einfach zu implementieren. Wenn Sie es sicherer machen möchten, schützen Sie es mit einem Passwort, d. H. Senden Sie die Anmeldung mit HTTPS-Post, und verwenden Sie dann die API innerhalb der authentifizierten Sitzung. – AlexR

+0

Okay, das stimmt. Dann bleibt nur noch eines übrig: Mit REST (Soap oder Hessian) ist der Client für das Empfangen und Abrufen von Daten zuständig. Ich kann das auch nicht haben ... der Client sollte vom Server auf neue Informationen aktualisiert werden, deshalb denke ich daran, einen que zu verwenden. Verschlüsseln Sie dies (wenn möglich) mit 128-Bit-Schlüssel Verschlüsselung (ich muss herausfinden, wie). –

 Verwandte Themen

  • Keine verwandten Themen^_^