1. solwrap/x.cpp + solclient.a -> libsolwrap.a
2. gosol.go + libsolwrap.a -> solace.plugin
3. application -> solace.plugin

• Meta data -> Header (destination, delivery mode, return address) + Properties (application properties)
• Body -> Payload/Attachment/Application Data

• Binary content—Binary data can be added to a message as a binary attachment. A message can only contain a single attachment.
• When this attachment is sent through the event broker, it is not processed, transformed, or considered in subscription matching or filtering operations. This provides an efficient means for sending data that does not require processing by the platform before it reaches receiving applications.
• Structured data can also be added as a payload in the binary attachment (refer to Using Structured Data).
• User Property Map—Structured data can be added to user-defined message header fields.
• User Data—Up to 36 bytes of application‑specific binary data, known as user data, can be added to the User Data message header field.
• Best Practices

• If you are sending a few headers that describe large content, consider setting the headers in the USER_PROPERTY map (set through solClient_msg_createUserPropertyMap(...)) and add the content using solClient_msg_setBinaryAttachmentPtr().
• When building a container, always try to accurately estimate the required size. The container could be a user property map (created through createUserPropertyMap()), a map (created in a message through solClient_msg_createBinaryAttachmentMap()) or a stream (created in a message through solClient_msg_createBinaryAttachmentStream(...)).
• When building a complex container that uses a submap or substream, write the submap or substream completely and call solClient_container_createStream(...) to finish the submap or substream before adding more to the main container.
• Add Data Payload

Direct messaging provides a reliable, but not guaranteed, delivery of messages from the Solace message bus to consuming clients, and is the default message delivery system for Solace PubSub+. It doesn't require any configuration beyond that required to set up and start other features. By default, direct messaging is always available to all clients connecting to an event broker.

• Aren't retained for a client when it's not connected to an event broker.
• Delivered to subscribing clients in the order in which publishers publish them.
• Don't require acknowledgment of receipt by subscribing clients.
• Aren't spooled on the message bus for consuming clients.
• Can be discarded when congestion or system failures are encountered.

• Extremely high message rates and extremely low latency are required.
• Consuming clients can tolerate message loss in the event of network congestion.
• Messages don't need to be persisted for later delivery to slow or offline consumers.
• Messages must be efficiently published to a large number of clients with matching subscriptions.

• A client disconnects from an event broker while messages are being published.
• A client fails to consume messages at the published rate and egress message buffer overflow results.

Guaranteed Messaging can be used to ensure the delivery of a message between two applications even in cases where the receiving application is off line, or there is a failure of a piece of network equipment. As well, those messages are delivered in the order they were published.

• It keeps messages that are tagged as persistent or non-persistent (rather than Direct) across event broker restarts by spooling them to persistent storage.
• It keeps a copy of the message until successful delivery to all clients and downstream event brokers has been verified.
• Messages accepted by Solace PubSub+ through Guaranteed Messaging for delivery to clients are never lost, but might not get accepted if system resource limits are exceeded.
• If an ingress message cannot be received by Solace PubSub+ (for example, if the spool quota is exceeded), the publisher is not acknowledged, and the appropriate event broker statistic is incremented.

Note: To support Guaranteed Messaging, an event broker must have message spooling enabled, and a Solace PubSub+ appliance must also have an Assured Delivery Blade (ADB) installed.

Note: Although a persistent delivery mode is typically used for Guaranteed messages, a non-persistent delivery mode is provided to offer compatibility with Java Message Service (JMS), and to allow the delivery mode of the messages to be modified to accommodate the persistence requirements of an endpoint or a client subscription when there is a topic match (refer to Topic Matching & Message Delivery Modes).

Solace endpoints are objects created on the event broker to persist messages. There are two types of endpoints: a queue endpoint (usually just called a queue) and a topic endpoint

• Topic endpoint is not the same as a topic.
• Topics are a message property the event broker uses to route messages to their destination, and they aren’t administratively configured on the event broker.

• Topic endpoints, are objects that define the storage of messages for a consuming application, and they do need to be provisioned on the event broker.
• Topic endpoints are more closely related to queues than to topics.

• Sending by Name: A producing application has the option to send a message directly to a queue by referencing that queue by its name in the message properties.
• A producing application cannot, however, reference topic endpoints by name, and therefore only persist messages routed to the topic subscription applied to the topic endpoint.
• Support for Multiple Topic Subscriptions: Queues support multiple topic subscriptions. This allows for topic aggregation to a single consuming application.
• Topic endpoints support a single subscription; should that subscription change, all messages persisted to the topic endpoint are deleted. Messages persisted in queues are unaffected by subscription changes.
• Application of Selectors: Selectors can be applied to either type of endpoint to apply conditional logic, but the two endpoints differ in when the conditional is processed. With queues, selectors are processed at egress, and with topic endpoints they are processed on ingress. This means that queues persist every message even if they don’t match the selector,
• while with topic endpoints messages are only persisted if they match both the topic subscription and the selector.
• Support for Multiple Consumers: Queues support multiple consumers, providing a fault tolerant option should a consuming application disconnect from the queue.
• Exclusive topic endpoints support a single consumer, matching the functionality of a JMS durable subscription.
• Non-exclusive topic endpoints can support multiple consumers for load balancing purposes.
• Ability to Read Without Removal: Finally, a queue can be read from without removing messages,
• whereas topic endpoints require the removal of messages to be read.

A non-durable endpoint, also known as a temporary endpoint, has a shorter lifecycle and can only be created by an application. The endpoint has a lifespan of the client that created it, with an additional 60 seconds in case of unexpected disconnect. The 60 seconds provides the client with some time to reconnect to the endpoint before it and its contents are deleted from the Solace broker.

• A durable endpoint is one that stays on the Solace broker until it is explicitly deleted.
• This endpoint can be created by an administrator, or dynamically created by an application.
• Durable endpoints are most often used when consuming applications require all messages including those received by the event broker when the application is disconnected.
• Through the client-profile object, an administrator can separately control whether an application is able to dynamically create its own durable or non-durable endpoints, and how many it is able to create.
• Endpoints also have their own permissions to control which applications can consume from them, modify them, and remove them.
• These permissions are set when the endpoint is initially created.
• If a client application creates an endpoint, it is automatically the owner of that endpoint and has full access to it.

• Queue Access Types

• The message spool is configured and enabled. The maximum spool usage is set to 1500 MB.
• The message VPN named default is enabled with no client authentication.
• The client username called default in the default Message VPN is enabled.
• The client username default has all settings enabled.
• All features are unlocked and do not require a product key.
• All services are enabled and the table below lists their default port numbers.

• 8080: Enables SEMP management traffic to the container. Use this port when connecting to the container using the PubSub+ Manager.
• 55555: Enables SMF data to pass through the container.