Channels, Streams and Sessions¶
When you create a Publication & Subscription pair, you must define both the Channel and Stream ID. The channel feels much like a standard TCP/IP configuration - it includes an IP Address and Port, at minimum. However, Aeron is not TCP/IP, and you can optionally use the same channel to move different streams of data - this is the Stream ID.
When you receive data from an Aeron Channel on a specific Stream ID and there is a single source of data, then the source is obvious. But what if there are multiple senders on that Channel and Stream ID? This is where Session ID helps - you can identify each source of data in a Subscription using the
header.sessionId() in the
From the subscriptions on the Server Process 1, the following information is available within a
|Client Process 1||server1:686||1||Session 213897|
|Client Process 2||server1:686||1||Session -421387|
|Client Process 3||server1:686||2||Session 2378636|
FragmentHandler cannot read the subscription channel - therefor
FragmentHandler objects don't do well when shared across different channels, but can work fine for sharing across different stream Id's on the same channel. You cannot construct different
FragmentHandler objects per session.
The developer should be aware that
sessionId values are integers, and can appear to be random with both positive and negative values found.
Impact on Ordering¶
Within Aeron, ordering is guaranteed only within the same
Image. When a subscription receives data, it aggregates the data of 0..m
Image objects. Each
Image is constructed per channel, stream and session. Note that if you have multiple
ExclusivePublication objects on the same channel and stream, they will each get their own
sessionId. This means that when multiple remote (or local, if
ExclusivePublication) sessions are sending to the same channel and stream ID, ordering is only guaranteed at a channel/stream/session level.
There is no total ordering across multiple sessions on the same channel and stream.
Using the Session ID with client-server operations¶
It's common to construct a protocol on top of Aeron, with the initial phase being some kind of
connect request operation (see RPC Server). One way to manage multiple client sessions within the same Subscription is to keep track of client connections via an Agrona
Long2ObjectHashMap which has the
sessionId as the key.