User Synchronization

Signature and Overview

The JSON body for user/syncrequest looks like this:

1
{
2
  "splitResponses": "boolean",
3
  "users": "number[]",
4
  "accounts": "number[]",
5
  "shardingExpression": {
6
    "divisor": "number",
7
    "remainder": "number",
8
    "expressionType": "modAccountId" | "modUserId"
9
  },
10
  "entityTypes": "string[]"
11
}

Parameters

• splitResponses (boolean, required) - Mandatory. Should be true for any B2B vendor.
• users (number[], optional) - Optional. Do not use if using shardingExpression or entityTypes.
• accounts (number[], optional) - Optional. Do not use if using Socket Sharding.
• shardingExpression (object, optional) - Controls sharding behavior.
  • divisor (number) - Total number of socket shards desired.
  • remainder (number) - If userId or accountId divided by divisor has a remainder of 1, they will come to the socket with remainder: 1.
  • expressionType (string) - Either "modAccountId" or "modUserId". Determines which entity type’s IDs are used for the modulus operation.
• entityTypes (string[], optional) - List of entity types you wish to receive.

Filter by Entity Type

To filter WebSocket updates by entity type, pass an entityTypes string array as described above.

This affects both the initial incoming dataset and the types of updates you receive over the socket’s lifetime.

Session Events

The userSessionStats entity updates every time a new authenticated session is created for the user, including plain REST sessions, not just new WebSocket connections. Because it is user-owned, the update fans out to all of that user’s subscribed sockets, so you may receive userSessionStats events without opening a new connection. These events are informational and are not a disconnect signal.

Sharding

What is Socket Sharding?

Sharding splits a workload among multiple instances to reduce load on any single actor. For our sockets, this means that if an actor fails, only a subset of users are affected.

Sharding Behavior

1. An entity change occurs.
2. The server looks at the entity ID and considers the expressionType config option passed to syncRequest.
3. The entity ID is divided by divisor—the remainder controls which socket the event is published to.
4. Create or Update “props” event is fired.
5. The vendor socket application processes the event.
6. Only the socket with the correct remainder receives the event.

For example, socket A with divisor = 3, remainder = 1 only receives updates when entityId % divisor == 1.

Sharding Gotchas

• remainder must be less than divisor. The server checks that divisor is greater than 0 and remainder is 0 or more, but it does not check that remainder is less than divisor. A shard with, for example, divisor: 3 and remainder: 5 is accepted and silently receives no events. Make sure your remainders cover 0 through divisor - 1.
• User-scoped entities skip modAccountId shards. Entities owned by the user rather than an account (such as userSession and userSessionStats) are not delivered to modAccountId shards. If you shard by account but also need user-level events, keep one additional unsharded (or modUserId) connection to receive them.

Implementation Example

Set up sharded socket instances by determining the total number of desired shards and configuring that many sockets with corresponding remainders.

1
// This function assumes you've created a class called Socket that wraps the actual WebSocket instance.
2
// This pseudo-version calls user/syncRequest as part of its startup routine, but you can configure
3
// the timing for the API command any sensible way you like.
4
function createSocketShard(
5
    accessToken: string, 
6
    divisor: number, 
7
    remainder: number
8
): Socket {
9
    return new Socket({
10
        url: 'https://demo-api.staging.ninjatrader.dev/v1/websocket',
11
        accessToken: accessToken,
12
        // The types filter used in syncRequest
13
        entityTypes: [
14
            'user',
15
            'account',
16
            'accountRiskStatus',
17
            'cashBalance',
18
            'fill',
19
            'accountRiskStatus'
20
        ],
21
        // The sharding expression used in syncRequest
22
        shardingExpression: {
23
            divisor,
24
            remainder,
25
            expressionType: 'modAccountId'
26
        }
27
    });
28
}
29
30
// Usage
31
const main = async () => {
32
  // You'll need to have acquired an access token,
33
  // here's a made-up function to grab one using the REST API
34
  const { accessToken } = await getAccessToken();
35
36
  // The shard function passes 3 as the divisor for each socket,
37
  // then we can set up the remainders configuratively.
38
  const socketA = createSocketShard(accessToken, 3, 0);
39
  const socketB = createSocketShard(accessToken, 3, 1);
40
  const socketC = createSocketShard(accessToken, 3, 2);
41
42
  // Subscribe to 'message' events on each socket instance.
43
  socketA.on('message', x => console.log('A', JSON.stringify(x)));
44
  socketB.on('message', x => console.log('B', JSON.stringify(x)));
45
  socketC.on('message', x => console.log('C', JSON.stringify(x)));
46
47
  // user/syncRequest is called as part of the connect routine
48
  await socketA.connect();
49
  await socketB.connect();
50
  await socketC.connect();
51
}
52
53
// Entry
54
main();