2008-11-10 6 views
14

Ich habe eine vorhandene eigenständige Anwendung, die von einem Drittanbieter unter Verwendung eines Netzwerkprotokolls erweitert wird. Die Fähigkeiten sind bereits implementiert, alles, was ich brauche, ist, sie nach außen zu bringen.Entwerfen eines Anwendungsprotokolls

Angenommen, das Transportprotokoll ist bereits ausgewählt (UDP), gibt es irgendwelche Ressourcen, die mir helfen, mein Anwendungsprotokoll zu entwerfen?

Es scheint eine Menge Informationen über Software-Design zu geben, aber nicht über das Protokoll-Design. Ich habe mir schon Application Protocol Design angesehen.

Antwort

4

Zunächst ist UDP in erster Linie eine Einweg-Broadcast-Transport-Methode. Es ist auch potenziell verlustbehaftet, so dass Sie in der Lage sein müssen, fehlende Pakete und Out-of-Order-Pakete zu behandeln. Wenn Sie ein hohes Maß an Zuverlässigkeit von UDP benötigen oder bidirektionale Verbindungen benötigen, werden Sie am Ende fast alles von TCP benötigen, also sollten Sie auch damit beginnen und sich vom Netzwerk-Stack kümmern lassen. Wenn Ihre Daten potentiell größer als ein einzelnes IP-Paket sind, benötigen Sie einen Weg, um den Anfang und das Ende jedes Pakets zu identifizieren, und eine Möglichkeit, illegale oder beschädigte Pakete zu bearbeiten. Ich würde eine Art Header mit Paketlänge, eine Fußzeile und vielleicht eine Prüfsumme empfehlen.

Dann brauchen Sie eine Möglichkeit zur Codierung der Nachrichten und Antworten. Es gibt viele RPC-Protokolle. Sie können sich SOAP ansehen oder ein benutzerdefiniertes XML-basiertes Protokoll oder ein binäres Protokoll erstellen.

+2

Es wäre wahrscheinlich vorzuziehen, unzuverlässig zu verlustreich zu verwenden. Nur zum Nicken: D – mdec

+1

UDP ist nicht nur verlustbehaftet, sondern kann auch Pakete außer Betrieb liefern. Das ist eklig. –

+0

warum benötigen Sie eine Fußzeile, wenn Sie das Längenfeld in der Kopfzeile haben –

0

Wenn Sie Ihr Protokoll nicht von Grund auf aufbauen möchten, sollten Sie einen Blick auf SOAP werfen. Die Unterstützung ist für verschiedene Programmiersprachen unterschiedlich, aber die sprachübergreifende Kommunikation wird ausdrücklich empfohlen.

Leider scheinen UDP und SOAP in den Kinderschuhen zu stecken, HTTP wird am häufigsten verwendet.

0

Wenn Sie sich für XML entscheiden, beachten Sie, dass Sie einen riesigen Overhead an Markup haben.

Ein einfaches binäres Protokoll wird auch brauchen nicht so viele Ressourcen zu analysieren im Vergleich zu XML.

5

Haben Sie sich Google Protocol Buffer angesehen? Es scheint eine gute Möglichkeit zu sein, dieses Problem zu lösen.

Sie können einen Endpunkt erstellen, der mit Ihrer vorhandenen App kommuniziert und dann über das Proto-Puffer-Protokoll von außerhalb antwortet. Es ist binär, also winzig und schnell, und Sie müssen keinen eigenen Protokollmanager schreiben, weil Sie die Google-Protokolle verwenden können. Der Nachteil ist, dass es auf beiden Seiten des Systems implementiert werden muss (auf Ihrer "Server" -Seite und auf der Consumer/Client-Seite).

+0

Beachten Sie, dass der/die RPC-Standard (en) noch nicht vollständig formatiert sind. –

0

Ich habe eine bestehende eigenständige Anwendung, die von einem Drittanbieter erweitert wird, unter Verwendung eines Netzwerkprotokolls.

Es würde helfen, ein wenig mehr darüber zu wissen, was Ihr Programm macht und was die Art dieser Drittanbieter-Erweiterungen sind. Vielleicht ein Grund für die Verwendung von UDP?

4

Eine weitere Empfehlung für protocol buffers - schön dicht binär mit wenig Aufwand. Beachten Sie jedoch, dass das binäre Protokoll zwar gut definiert ist, aber noch kein vereinbarter RPC-Standard (several are in progress, Tendenz zu TCP oder HTTP) vorliegt.

Die Spezifikation macht es sehr einfach, den Client und Server in different architectures zu haben, was gut ist - plus es ist erweiterbar.

Caveat: Ich bin der Autor eines der .NET versions, so dass ich kann gut ;-p

1

Sie sollten wirklich darüber nachdenken, ob Sie wirklich Ihr eigenes Protokoll entwerfen, dokumentieren und pflegen oder etwas verwenden wollen, das bereits existiert. Wahrscheinlich gibt es bereits ein dokumentiertes Protokoll, das Ihren Anforderungen entspricht. Abhängig von dem, was Sie tun, wird es wahrscheinlich Overkill zuerst aussehen und die Umsetzung der Spezifikation wird langweilig und viel weniger Spaß als das Schreiben Ihrer eigenen, aber wenn Sie beabsichtigen für Ihre Anwendung noch in einigen Jahren aktiv entwickelt werden, sollte es Sie speichern viel Zeit und Geld, um etwas zu nutzen, das bereits existiert und von Dritten bekannt ist. Wenn Sie eine vorhandene Bibliothek für dieses Protokoll verwenden können, sollte der Implementierungsteil außerdem viel schneller sein.

Das Entwerfen eines neuen Protokolls macht mehr Spaß als das Implementieren eines, aber weniger als das Aufrechterhalten eines, da Sie mit allen Defekten leben müssen. Kein Protokoll ist perfekt, aber wenn Sie noch nie einen entwickelt haben, können Sie sicher sein, dass Sie mehr Fehler beim Entwerfen machen werden als die Leute, die das existierende bekannte Protokoll entworfen haben, das Sie stattdessen verwenden könnten.

Kurz gesagt, Hebel, was bereits vorhanden ist, wann immer es möglich ist.