Creating Client Sessions

A Session creates a single, client connection to a Solace PubSub+ event broker for sending and receiving messages. The Solace Message Format (SMF) is used to facilitate the communication between a client and an event broker, and this SMF communication is then encapsulated through a single TCP connection.

A Session can also use a shared memory transport when using the Inter‑Process Communications (IPC) capabilities of the Solace C API; for more information refer to Configuring Inter-Process Communications. However, shared memory transport and IPC capabilities are not available when using the C API for iOS applications.

By default, Sessions are unsecured—in a connected Session, the SMF data sent between a client and an event broker is transmitted as plain text. However, it is also possible to establish a secure Session that uses Transport Layer Security (TLS)/ Secure Sockets Layer (SSL) protocols so that the SMF data is encrypted. For information on how to configure specific TLS/SSL Session properties and establish a secure Session, refer to Creating Secure Sessions.

Sessions are always created within a Context. The client application controls whether one or multiple Sessions are grouped under a processing Context. Once a Session is created within a given Context, it remains associated with that single Context until it is disposed.

To create a Session, the client application must provide the following:

  • Session properties

    Properties used to customize the Session. Any Session property that is not explicitly supplied is set to default values. Although the defaults can be used in many cases, some client and event broker parameters require specific input from the client to establish a connection to a Message VPN on an event broker. Refer to Session Properties Required to Establish a Connection.

  • Specific Context instance

    For JCSMP, if you want to use a Context other than the default Context, you can pass in a specific Context to the factory method.

  • Session event callback or delegate

    For the Java RTO, C, or .NET APIs, a Session event callback or delegate must be specified when creating a Session. This callback or delegate is invoked for each Session event. Refer to Handling Session Events.

    A Session event callback is optional for JCSMP.

  • Message receive callback or delegate

    For the Java RTO, C, or .NET APIs, a message event callback or delegate must be specified when creating a Session. This callback or delegate is invoked each time a Direct message is received through the Session. Refer to Receiving Direct Messages.

    For JCSMP, Direct messages delivered to a Session are received through a com.solacesystems.jcsmp.Consumer, which is acquired by the client application after the Session is created.

Once a Session is created, it must be connected. ForJCSMP, explicitly calling connect is recommended as best practice; although the API will automatically attempt to connect when requesting a producer or consumer. For the Java RTO, C, and .NET APIs, you must use the Session connect calls listed below.

To Create a Session
PubSub+ Messaging API Use

JCSMP

  • JCSMPFactory.createSession(...)

    Creates a Session.

  • JCSMPSession.getMessageConsumer(...)

    Registers a message callback.

Java RTO

  • ContextHandle.createSessionForHandle(...)

    Creates a Session that is bound to an unbound SessionHandle.

C

solClient_session_create(...)

.NET

IContext.CreateSession(...)

JavaScript and Node.js

  • solace.SolclientFactory.createSession(...)

    Creates a Session.

  • Session.on(...)

    Registers a session event listener, e.g.: for a MESSAGE event.

To Connect a Session
PubSub+ Messaging API Use

JCSMP

Session.connect()

Java RTO

SessionHandle.connect()

C

solClient_session_connect(...)

.NET

ISession.Connect()

JavaScript and Node.js

Session.connect()

To Close a Session
PubSub+ Messaging API Call

JCSMP

Session.closeSession()

Java RTO

  • SessionHandle.disconnect()

  • SessionHandle.destroy()

Destroying the session is not required.

C

  • solClient_session_disconnect(...)

  • solClient_session_destroy(...)

Destroying the session is not required.

.NET

  • ISession.Disconnect()

  • ISession.Dispose()

Disposing of the session is not required.

Javascript and Node.js

  • Session.disconnect()

  • Session.dispose()

  • When using the Java RTO, C, JavaScript, Node.js, or .NET APIs, calling destroy or dispose to destroy a session object is not required. If the Session object is not destroyed, you may reconnect to it at a later time.
  • When using the C or .NET APIs, if a Session is destroyed/disposed or a global cleanup is performed, any buffered messages associated with that Session are discarded before it is disconnected. When a Context is destroyed/disposed, the buffered messages associated with every Session contained within that Context are discarded.
  • When using the Javascript or Node.js APIs, calling dispose releases all resources associated with the session. Solace recommends calling disconnect first for a proper handshake with the event broker.

Related Samples

For an example of how to create and connect Sessions, refer to the DirectPubSub sample for the Java, Java RTO, C, and .NET APIs, and the TopicPublisher sample for the JavaScript and Node.js APIs.