2014-01-09 4 views
9

Stellen Sie sich vor, dass Server und Client über WebSocket sprechen. Jede Zeit sendet weitere Datenblöcke. Verschiedene Stücke können unterschiedliche Länge haben.Ist Websocket ein strombasiertes oder paketbasiertes Protokoll?

Bin ich garantiert, dass, wenn der Server Chunk in einem Anruf sendet, der Client es dann in einem message Callback erhält und umgekehrt? D. h., WebSocket hat die Fähigkeit zum "Verpacken" integriert, so dass es mir egal ist, ob meine Daten während der Übertragung zwischen mehreren Rückrufen aufgeteilt werden oder nicht?

+0

http://StackOverflow.com/Q/21024173/632951, http://StackOverflow.com/A/13011241/632951 – Pacerier

Antwort

5

Theoretisch präsentiert das WebSocket-Protokoll ein nachrichtenbasiertes Protokoll. Beachten Sie jedoch, dass ...

  • WebSocket-Nachrichten bestehen aus einem oder mehreren Frames.
  • Ein Rahmen kann entweder ein kompletter Rahmen oder ein fragmentierter Rahmen sein.
  • Nachrichten selbst haben keine Längenangabe in das Protokoll eingebaut, nur Frames.
  • Frames können eine Nutzdatenlänge von bis zu 9.223.372.036.854.775.807 Bytes haben (aufgrund der Tatsache, dass das Protokoll einen 63-Bit-Längenindikator ermöglicht).
  • Der primäre Zweck der Fragmentierung besteht darin, das Senden einer Nachricht unbekannter Größe zu ermöglichen, wenn die Nachricht gestartet wird, ohne diese Nachricht puffern zu müssen. So

...

Eine einzelne WebSocket "Nachricht" könnte von einer unbegrenzten Anzahl von 9.223.372.036.854.775.807 Byte-Fragmenten bestehen.

Dies erschwert eine Implementierung über seine API Sie vollständige Nachrichten liefern immer machen kann ...

Während also im allgemeinen Fall die Antwort auf Ihre Frage, dass das WebSocket-Protokoll ist eine Nachricht Protokoll und Sie müssen Ihre Nachrichten nicht manuell umrahmen. Die API, die Sie für die Verwendung des Protokolls verwenden, verfügt möglicherweise über Beschränkungen für die Nachrichtengröße (um die Zustellung von Nachrichten als einzelnen Chunk zu garantieren) oder eine Streaming-Schnittstelle, um Nachrichten in unbegrenzter Größe zuzulassen.

Ich habe über das zurück während des Standardisierungsprozesses here.

+1

alte Ratte (ca. 2011), die meisten Punkte sind strittig, ungültig oder adressiert jetzt in den verschiedenen realen Implementierungen von Websocket. –

+0

Nun, wir werden zustimmen zu widersprechen, denke ich, es sei denn, Sie möchten den betreffenden Blogpost kommentieren und darauf hinweisen, wie es jetzt falsch ist; dann können wir diskutieren. Die Tatsache, dass die Implementierungen "CAN" und "DO" eigene Work arounds (wie die Größenbeschränkung der Nachrichten) hervorbringen, ändert nichts an der Tatsache, dass die Protokollspezifikation für das oben gezeigte Verhalten erlaubt und, IMHO, unglücklich ist und/hätte zu der Zeit behandelt werden können. –

+0

Ich denke, dass alle, die in die Diskussion involviert sind, das sind, was ich Experten für Networking und WebSocket nennen würde;) Aber ich möchte etwas auf andere Leser hinweisen: Ich denke, es lohnt sich, zwischen _API_ und _Protocol_ zu unterscheiden. Eine WebSocket-API kann WebSocket auf verschiedenen Ebenen verfügbar machen: pro Nachricht, pro Frame oder Streaming. Und selbst mit einer Streaming-API kann die Implementierung Nachrichtengrenzen offen legen. In jedem Fall basiert das WebSocket-Protokoll selbst auf Nachrichten (und Frames).Und es _erfordert_ Nachrichtengrenzen zu erhalten - aber nicht Rahmengrenzen. – oberstet

4

WebSocket ist ein nachrichtenbasiertes Protokoll. Wenn Sie also einen Teil der Daten als Payload einer WebSocket-Nachricht senden, erhält der Peer eine separate WebSocket-Nachricht mit genau diesem Datenpaket als Payload.