WebSocket STOMP Protocol

From sgcWebSockets 4.1.6 STOMP protocol is supported.

STOMP is the Simple (or Streaming) Text Orientated Messaging Protocol. STOMP provides an interoperable wire format so that STOMP clients can communicate with any STOMP message broker to provide easy and widespread messaging interoperability among many languages, platforms and brokers.

Our STOMP client components supports following STOMP versions: 1.0, 1.1 and 1.2.



This is Client Protocol STOMP Component, you need to drop this component in the form and select a TsgcWebSocketClient Component using Client Property.



  Send: The SEND frame sends a message to a destination in the messaging system.

  Subscribe: The SUBSCRIBE frame is used to register to listen to a given destination.

  UnSubscribe: The UNSUBSCRIBE frame is used to remove an existing subscription.

  ACK: ACK is used to acknowledge consumption of a message from a subscription.

  NACK: NACK is the opposite of ACK. It is used to tell the server that the client did not consume the message.

  BeginTransaction: is used to start a transaction. Transactions in this case apply to sending and acknowledging - any messages sent or acknowledged during a transaction will be processed atomically based on the transaction.

  CommitTransaction: is used to commit a transaction in progress.

  AbortTransaction: is used to roll back a transaction in progress.

  Disconnect: use to graceful shutdown connection, where the client is assured that all previous frames have been received by the server.



  OnSTOMPConnected: this event is fired after a new connection is established.

    version : The version of the STOMP protocol the session will be using. See Protocol Negotiation for more details.

    STOMP 1.2 servers MAY set the following headers:

    heart-beat : The Heart-beating settings.

    session : A session identifier that uniquely identifies the session.

    server : A field that contains information about the STOMP server. The field MUST contain a server-name field and MAY be followed by optional comment fields delimited by a space character.


  OnSTOMPMessage: this event is fired when client receives a message.

  The MESSAGE frame MUST include a destination header indicating the destination the message was sent to. If the message has been sent using STOMP, this destination header SHOULD be identical to the one used in the corresponding SEND frame.

  The MESSAGE frame MUST also contain a message-id header with a unique identifier for that message and a subscription header matching the identifier of the subscription that is receiving the message.

  If the message is received from a subscription that requires explicit acknowledgment (either client or client-individual mode) then the MESSAGE frame MUST also contain an ack header with an arbitrary value. This header will be used to relate the message to a subsequent ACK or NACK frame.

  MESSAGE frames SHOULD include a content-length header and a content-type header if a body is present.

  MESSAGE frames will also include all user defined headers that were present when the message was sent to the destination in addition to the server specific headers that MAY get added to the frame.


  OnSTOMPReceipt: this event is fired once a server has successfully processed a client frame that requests a receipt.

  A RECEIPT frame is an acknowledgment that the corresponding client frame has been processed by the server. Since STOMP is stream based, the receipt is also a cumulative acknowledgment that all the previous frames have been received by the server. However, these previous frames may not yet be fully processed. If the client disconnects, previously received frames SHOULD continue to get processed by the server.


  OnSTOMPError: this event is fired  if something goes wrong.

  The ERROR frame SHOULD contain a message header with a short description of the error, and the body MAY contain more detailed information (or MAY be empty).

  If the error is related to a specific frame sent from the client, the server SHOULD add additional headers to help identify the original frame that caused the error. For example, if the frame included a receipt header, the ERROR frame SHOULD set the receipt-id header to match the value of the receipt header of the frame which the error is related to.

  ERROR frames SHOULD include a content-length header and a content-type header if a body is present.



 Authentication: disabled by default, if True an UserName and Password are sent to server to try user authentication.

 HeartBeat: Heart-beating can optionally be used to test the healthiness of the underlying TCP connection and to make sure that the remote end is alive and kicking. In order to enable heart-beating, each party has to declare what it can do and what it would like the other party to do. 0 means it cannot send/receive heart-beats, otherwise it is the desired number of milliseconds between heart-beats.

 Options: The name of a virtual host that the client wishes to connect to. It is recommended clients set this to the host name that the socket was established against, or to any name of their choosing. If this header does not match a known virtual host, servers supporting virtual hosting MAY select a default virtual host or reject the connection.

 Versions: Set which STOMP versions are supported.