As our documentation states, the TWebSocketProtocolBinary class implements a binary proprietary protocol, with optional frame compression and AES encryption (using AES-NI hardware instructions, if available).

This protocol, even if it is implemented as REST compatible, as several unique features:

  • The requests are converted into binary frames, optionally compressed (using SynLZ) and encrypted;
  • Since encryption is at frame level, you would avoid the need to use an additional TLS (aka wss://) layer, which is resource consuming and not obvious to configure;
  • If the SOA method does not require any answer (i.e. if the Delphi interface method is a procedure without any out parameter), the corresponding frame won't be blocking, and would be added in an in-memory list - of course, you can disable this feature on request;
  • The framework is able to gather several pending frames into a single bigger message (a kind of "jumbo frame"), to reduce the resource use - this makes a huge difference over a slow network, e.g. over the Internet, where the latency could be noticeable.

Our latest commit ensures that the gathered "jumbo frame" is compressed and encrypted as one.
Initial implementation did concatenate the already encrypted/compressed smaller frames before transmission.
This new behavior will reduce the CPU cost, and also the message size, since compressing a big frame is much more efficient than compressing several smaller frames, by definition.

But the previous transmitted data is not compatible with this new layout.
As a consequence, you should upgrade both client and server sides of any application using our WebSockets binary protocol.
Once we would release a stable version of the framework (the current unstable 1.18 branch would probably become stable 2.0), this format should not change.

Of course, the JSON protocol (TWebSocketProtocolJSON) is not impacted by this change.