Clients getting duplicate connection message

ServiceStack 5.8.0 on Windows Server 2016 (and 4.5.12 on clients)

Recently have noted that on occasion some of the clients connected to the server [via ServerEvents] are getting the same Connection Event;
Client A:
2020-04-25 11:58:13,283 [29] DEBUG ServiceStack.ServerEventsClient - [SSE-CLIENT] OnConnectReceived: 0 on #user23 / EhjDwN9NdctAOOPlByYx on (server)

Client B:
2020-04-25 11:58:13,485 [52] DEBUG ServiceStack.ServerEventsClient - [SSE-CLIENT] OnConnectReceived: 0 on #user23 / EhjDwN9NdctAOOPlByYx on (server)

This appears to happen after a heartbeat gets an exception and the client reconnects.
2020-04-25 11:58:10,000 [99] DEBUG ServiceStack.ServerEventsClient - [SSE-CLIENT] Error from Heartbeat: The remote server returned an error: (404) Not Found.

The server appears to only get the one subscription created event:
2020-04-25 11:58:13,285 INFO [39 ] EventSubscription: created. C=server D=user23 S=3WTbYZgkzTiNljysgf9U SU=EhjDwN9NdctAOOPlByYx

On the clients, at their next heart beat they get an exception:
2020-04-25 11:59:13,680 [49] DEBUG ServiceStack.ServerEventsClient - [SSE-CLIENT] Error from Heartbeat: The remote server returned an error: (403) Forbidden.

which causes them to reconnect and thankfully get a new [and unique this time] connection and subscription-id.

The issue I have is between the time of the connection and the first heart beat [approx 1 minute] my server can [and has] attempted to send a notification to a specific client using their subscriber-id. Because of the duplicates (and the way the server is being told which client has which subscriber-id) this notification can go to the wrong client.

I have added some code to trap when my server gets a notification from a new client which has the same subscription-id as an existing client to hopefully alleviate this situation, but was wondering if you have any suggestions on why this may be happening?

You should look into updating the clients, v4.5.12 is very old, when they’re expected to be in-sync with the server.

The forbidden response is when a user with a different address tried to access a subscription (e.g. heartbeat, update or unregster) that was created with a different IP Address. You can disable this check with:

new ServerEventsFeature {
    ValidateUserAddress = false,
}

Thanks. Updating the clients will not always be possible and timely … unfortunately.

As for the Forbidden - I actually am glad about receiving that - as at least it means the clients do reconnect and get a valid connection …

Is there a way with the clients - to pass some information when they connect? I’m not talking about authentication - but just some client specific information that the server could parse ?

The C# Clients have a EventStreamRequestFilter which lets you modify the HttpWebRequest used to connect to the client.

Any Request Info will be available on the IRequest when the OnCreated Event is called. The IEventSubscription has a Meta string dictionary you can use to attach additional metadata to the Event Subscription.