Yeah IClientProxy doesn't have the Abort method. It's just available in the hub context. I'd suggest invoking a method on client side which will gracefully disconnect then.

We don't really support this from HubContext, but it's something to consider for the future. A graceful shutdown based on invoking a "Shutdown" method on the client is more appropriate here, as @atresnjo suggests. Abruptly terminating connections should generally only be used when the client is unresponsive for uncooperative.

It's difficult to add this ability to the HubContext because in a multi-server scenario (when scaling), we don't know if the code that's calling "Abort" is running on the same server as the connection. If it's not, then we have to send that information to the appropriate server, which has a whole bunch of other issues behind it.

I want client to directly invok OnDisconnectedAsync method (public override async Task OnDisconnectedAsync (Exception exception) ) of Hub class. Is this a best practice ?

@bluetianx

No. Implement your own method and invoke it when needed.

Something like:

public class ServerHub : Hub
{
}

public class ClientHub : Hub
{
    public ClientHub()
    {
        hubConnection.On<string>("Shutdown",
            ShutdownReceived);
    }

    public void ShutdownReceived(string reason)
    {

    }
}

public class ShutdownService
{
    private readonly IHubContext<ServerHub> _hubContext;
    public ShutdownService(IHubContext<ServerHub> hub)
    {
        _hubContext = hub;
    }

    public void SendShutdown()
    {
        _hubContext.Clients.All.SendAsync("Shutdown", "Reason");
    }
}

You may have misunderstood me. My demo code is as follows ：

-----server code

public class NotificationHub:Hub
{

        public override async Task OnConnectedAsync()
        {
            await base.OnConnectedAsync();
        }
        public override async Task OnDisconnectedAsync(Exception exception)
        {
            // deleteOffLineUser();
            await base.OnDisconnectedAsync(exception);
        }
        public async bool ShutDown(string reason)
        {
            //TODO
            // delete connect record  from database
            await base.OnDisconnectedAsync(null);
            return true;
        }
}

// webAPI

Route("api/[controller]")]
    [ApiController]
    public class ValuesController : ControllerBase
    {
        private readonly IHubContext<NotificationHub> _hubContext;
        [HttpPost]
        public bool DisconnectUser1()
        {
            _hubContext.Clients.All.SendAsync("Shutdown", "reason");
        }

        [HttpPost]
        public bool DisconnectUser2()
        {
            _hubContext.Clients.All.SendAsync("DIsconnect", "reason");
        }
        
    }

// web client JS

var connection = new signalR.HubConnectionBuilder().withUrl("http://localhost:5050/notificationhub").build();

    connection.on("Shutdown", function (message) {
        connection.invoke("Shutdown", message);
    });
    
    connection.on("Disconnect", function (message) {
        connection.invoke("OnDisconnectedAsync", null);
    });
    
    connection.start().catch(function (err) {
        console.log(err.toString());
        return console.error(err.toString());
    }).then(function(data) {
        //connection.invoke("Register", userId);
    });

I want to disconnect connection of HTTP, Such as websocket , Should I request DisconnectUser1 or
DisconnectUser2 by WebAPI.

Do not call OnDisconnectedAsync manually. It will not do what you expect.
OnDisconnectedAsync is called when the connection is terminated. So in your Shutdown method you can call Context.Abort(); which will then trigger the OnDisconnectedAsync method correctly.

connection.on("Shutdown", function (message) {
    connection.invoke("Shutdown", message);
});

connection.on("Disconnect", function (message) {
    connection.invoke("OnDisconnectedAsync", null);
});

In these cases, you can just use connection.stop on the client to disconnect. There's no reason to call OnDisconnectedAsync. And, as @BrennanConroy said, it will not work to call it manually.

Here's a complete sample that will allow you to signal a client to disconnect from the server outside the Hub:

NotificationHub.cs:

public class NotificationHub: Hub
{
    // You don't need any code here to specifically support this. But if you want to
    // run code when a client does disconnect, you can override OnDisconnectedAsync
}

Client.js

var connection = new signalR.HubConnectionBuilder().withUrl("http://localhost:5050/notificationhub").build();

connection.on("RequestShutdown", function (reason) {
    console.log("Server requested we disconnect because: " + reason);
    connection.stop();
});
    
connection.start().catch(function (err) {
    console.log(err.toString());
    return console.error(err.toString());
}).then(function(data) {
    // Do startup things
});

WebAPI.cs

[Route("api/[controller]")]
[ApiController]
public class ValuesController : ControllerBase
{
    private readonly IHubContext<NotificationHub> _hubContext;

    [HttpPost]
    public bool DisconnectUser(string userName)
    {
        _hubContext.User(userName).SendAsync("RequestShutdown", "reason");
    }
}

OK,I understand,Thank you very much @atresnjo @anurse @BrennanConroy

Blocked by #3284

Has there been any progress made on this issue?
Can the server disconnect a client without having to send a message to the client?
@anurse @BrennanConroy

It's still in the backlog. Let us know your scenario though and it will help us prioritize this work in a future release!

We are developing an MMO game, and we are in the process of switching over to use SignalR.

The functionality we have not been able to port over to SignalR includes:

• When the server needs to go down for maintenance, we disconnect all connected players and stop accepting new connections.
• When a player is displaying bad behavior, a Game Master can kick the player from the server.

In both of these scenarios, the server needs to have the authority to disconnect players without sending a disconnect request.

That makes sense! Thanks for the info.

For us, this would also be a very important feature.

We are working on a new backend for a game. There are many scenarios where a client could not be cooperative and will try to cause harm - in which case we have to forcefully close the connection from the server. In addition, we also have similar scenarios like those described by @thorgeirk11

Modifying the client and changing any client-side disconnection logic in order to ignore the requested disconnect from the server is trivial.
This is a very important and security-critical feature. Even if we can disallow a client to execute any further logic on the server, the underlying connection will stay open, since the server cannot close it.
I think this should have been possible from the first-ever version.
Please consider assigning this a high priority. @anurse @BrennanConroy

There is likely a workaround way to implement this right now. The necessary logic should already exist in the Hub itself (via Context.Abort()). The request here is to be able to do it from outside the hub.

While we don't generally recommend doing this, it is currently OK to capture the HubCallerContext (from the Context property) in OnConnectedAsync, store it somewhere (a dictionary indexed by ConnectionID perhaps) and then call .Abort() on it to terminate the connection.

I do agree that we should look at a more first-class way to do this, but I'd be curious if this workaround works for your scenario. Would you be able to try it and report back? We'll look at this for 5.0, but that's not coming until November 2020 and I'd like to be able to give you something that works before then :).

An important note about my workaround: This will only work on the physical server process on which the client is connected. It will not be possible to forcibly disconnect a connection that resides on a different physical server process (in a scenario where you have multiple servers connected via a backplane like Redis or Azure SignalR).

Honestly, I'd expect the first-class solution to have a similar restriction, since it's very tricky to make that work reliably (since we don't have a single source of truth for which connections exist and on which servers they reside).

There is likely a workaround way to implement this right now. The necessary logic should already exist in the Hub itself (via Context.Abort()). The request here is to be able to do it from outside the hub.

While we don't generally recommend doing this, it is currently OK to capture the HubCallerContext (from the Context property) in OnConnectedAsync, store it somewhere (a dictionary indexed by ConnectionID perhaps) and then call .Abort() on it to terminate the connection.

I do agree that we should look at a more first-class way to do this, but I'd be curious if this workaround works for your scenario. Would you be able to try it and report back? We'll look at this for 5.0, but that's not coming until November 2020 and I'd like to be able to give you something that works before then :).

I was thinking about storing the HubCallerContext and using it outside a hub, but I was not sure if it was safe (ie. HubCallerContext instance might be different every call). I will gladly try it and report back once we are testing our SignalR code. Thank you for the quick help!

I was not sure if it was safe

It should be safe. I do want to clarify that it's a bit of an unsupported path. I don't expect we'd break it (and certainly not until we have a first-class way to disconnect a specific client) but I would definitely put some comments in there referencing this issue and plan to switch to the actual feature once we get one in ;). It may be that we just make this a fully-supported thing (capturing the HubCallerContext). There's nothing terribly wrong with doing it, it's just not something we have documentation and tests in place for :).

As useful as this feature is I don't think we should implement anything that needs to communicate across servers over the backplane to take an action on a connection. Aborting the socket needs to happen from the server where that socket is. It's simple an reliable (at least is should be) and there's no possibility of missing the notification because redis went down or because a backplane is poorly written.

This one of the major reason the old version of SignalR has such gnarly reliability bugs and those mistakes shouldn't be repeated here. SignalR needs to remain a super thin layer of RPC over WebSockets with some nice ways to send/receive messages with different protocols.

@davidfowl et al; I am using SignalR for sending notifications to clients in a social app (ASP.NET sever and Xamarin .NET client). It is of utmost importance that when a client logs out (either from the current session, or all of his sessions), that the server aborts connections to said client. I can not rely on the client aborting the connection itself; no the server must obey when a client requests a disconnection. In no scenario can a connection remain open to a client after he has requested a disconnection or I won't be able to ship my product, as it is trivial to hack a client to not obey.

I have implemented what was suggested here, ie I cache the context object in a ConcurrentDictionary in a singleton service. @davidfowl you said that even when Abort() is fully supported outside of a hub you won't implement it "at scale". My plan was to use the SignalR Service on Azure.
So how can I ensure that the server actually disconnects a client when need be, after deploying my server to the SignalR Service? This is not a "nice to have" feature but an absolute requirement for any application that deals with personal and/or sensitive information. If I understand your guidance correctly, even when saving the context Abort() will only work for clients that are connected to the same server where Abort() is called. That is not good enough, so eagerly awaiting for guidance on this.

Also, is it possible that I'll run into memory issues by saving the context object? I have to do it now as there is no supported way to call Abort() outside of the hub, but I want to make sure I am not opening up more problems by following this guidance.

Thanks.

Abort works fine on the Azure signalr service and that’s the way to do it

Abort works fine on the Azure signalr service and that’s the way to do it

Thank you. It was not clear to me that Azure SignalR service would work out of the box. Thanks for the clarification.

An important note about my workaround: This will only work on the physical server process on which the client is connected. It will not be possible to forcibly disconnect a connection that resides on a different physical server process (in a scenario where you have multiple servers connected via a backplane like Redis or Azure SignalR).

@davidfowl @anurse I'd like to just verify that it will indeed work with the Azure SignalR service at scale, as @anurse wrote in the quoted section that it won't. So I have conflicting information here.

Thank you.

@davidfowl @anurse Hi, is there any way you guys could confirm whether calling Abort() works in all cases when using the SignalR service? @anurse said it only works when they are on the same server, while @davidfowl said it works fine in all cases.

I will be deploying my server with the SignalR service. My server sends notifications to connected clients through SignalR. It also provides a REST API where clients can log out, in which case the server revokes his access token and calls Abort() on any connection(s) the client may have. Is it guaranteed that Abort() will break the pipe to the user in all cases in this scenario?
The connection sends, amongst other things, chat messages so it is paramount that the connection is severed on the server side when a client requests so.

If it works, fantastic, if not, what is the guidance on how to work around this?

Thank you so much!

really need a way to disconnect Clients/Users from the server side, API like below:
Clients.Users( [userIds] ).Disconnect();
Clients.Clients( [connectionIds] ).Disconnect();

should remove all those connectionIds from the joined Group automatically when call those APIs.

to manually bookkeeping the connectionId and intercept the call to Hub then call Context.Abort() if Context.connectionId match the saved connectionId,

there is too much work to do out of the lib and hardly do it right by the application developers.

if simply one server, keep in the memory is fine, but if want to scale, say, with Redis, then need another different implimentation,to keep the connectionId in the redis as well.

better to have this feature in the signalr lib itself, and can scale the same way like scale out signalr.

I also want an answer to the question @Tommigun1980 asked earlier:

One final question (I promise!) - I need to know if a user is connected at the time when trying to send a message. If he's not I would like to send a push instead. There seems to be no API for this and no return values from the RPCs (presumably to avoid additional data transfers), so I guess this is tangentially related to the whole Abort() thing. Is there any mode, API or anything, that could give this information when scaling out with the service? If not I think I'll go down the route you kinda suggested earlier, with another server where hubs notify of and can poll for connection status.

In the end my use case is really simple - I want to send a push if a client is offline, else make an RPC notification call.

How can this be achieved if connections are shared between multiple machines, and when call REST api endpoint, I cannot know for sure if the client is connected or not on the machine where the REST api call originated?
Thanks!

How can this be achieved if connections are shared between multiple machines, and when call REST api endpoint, I cannot know for sure if the client is connected or not on the machine where the REST api call originated?

By storing the presence information in a database and checking that information when you want to send the message to the client. If the message is server generated then you don't need send a message.

You can build a system that polls the status of connections on each node/machine/pod/compute unit and abort connections that are marked for abort.

There are lots of ways to build this functionality

@davidfowl , Good idea! Thanks

There's no way to implement this feature in a distributed system efficiently in a way where you can always know if the person in online or offline before sending a message. Once you accept that then you'll recognize that you need to adjust the application behavior to deal with the potential to send a message to the client that isn't there and deal with the fallout of that.

Signalr doesn't give any feedback about messages being received by the client.

That said I do think presence information is useful and maybe will be in the service one day.

As for the client acks, there is an issue for it here #5280

There's no way to implement this feature in a distributed system efficiently in a way where you can always know if the person in online or offline before sending a message. Once you accept that then you'll recognize that you need to adjust the application behavior to deal with the potential to send a message to the client that isn't there and deal with the fallout of that.

Signalr doesn't give any feedback about messages being received by the client.

That said I do think presence information is useful and maybe will be in the service one day.

Hi and thanks for the reply.

This doesn’t need to be known before the fact. At some point some part of your service has to make the decision for whether to send (ie does a connection exist), right? Could this information be trickled back?

It is an extremely common use case to send a push if a user is not connected, and for this it needs to be known whether any connection exists to a user.

It may be somewhat tricky, but this is the exact reason why I’m using your service in the first place. To solve these things for me.

Thank you again for considering.

And to clarify, I only need to get back whether the service tried to send the message.

bool connected = await client.Send(x);
if (!connected)
    // send push

The send call goes through your system through various parts, until some part ultimately takes the decision whether to proceed or abort. Every part in the chain trickles this information up.

Why wouldn’t this be possible? This would save us from recreating the service.
I don’t think the service is complete in any way without this feature as it’s such a common use case.

Thank you again.

Between the send and the call you make to send a push notification. The client can be back online. Then what?

Also, if this was a real problem it would be a thousand times worse by having to make a separate call first to see how to proceed.

The best most efficient way is for the service to return this info, it can’t get any better than that.

And I’ll elaborate a bit even further:

The other option is to always also send a push (ie send message + push).
Why not do it?

1. Cost
2. OS vendors will start throttling your pushes if you do that
3. If the user has multiple devices, his non-active devices would be constantly pinging with notifications while he uses the app

So only sending a push when needed is the way to go.

If the client connects a millisecond after the server checks connection status, and sends one "unnecessary" push - what’s the harm? It’s the best we can do, how every app works, and it doesn’t have negative effects. We were operating on the information available at the time, and it’s the best we can ever do (unless we implement time travel).

Today the presence information isn't provided by the service so you need to do that, it's not about the send itself, it's about this information and it isn't tied to the call to send. Just use that information to send the push notification based on the current state even if it is potentially out of sync. As long as your application can handle the eventual consistency of it (and it has to), then it's fine.

I understand that. Hence my suggestion to not just "fire and forget" the call, but to send back the information all the way to the caller.

While that's a separate issue, I don't think we'd add the API for this scenario. If you choose to use it for that, that's great, but the purpose of that issue is to return results from the client, not to detect if that client is online. Maybe you can use a failure to retrieve the result as the way to detect the offlineness.

I understand that. Hence my suggestion to not just "fire and forget" the call, but to send back the information all the way to the caller.

While that's a separate issue, I don't think we'd add the API for this scenario. If you choose to use it for that, that's great, but the purpose of that issue is to return results from the client, not to detect if that client is online. Maybe you can use a failure to retrieve the result as the way to detect the offlineness.

I would love to do that, but I am failing to see how.

This is my current implementation:

public async Task SendNotification(
    Guid accountId,
    Func<IClient, Task> RPCCallAction = null,
    Func<Task<PushMessage>> pushMessageGetter = null)
{
    if (RPCCallAction == null && pushMessageGetter == null)
        return;

    if (await this.IsConnected(accountId))
    {
        if (RPCCallAction != null)
        {
            var clientInterface = this.connectionHub.Clients.Group(accountId.ToString());
            await RPCCallAction(clientInterface);
        }
    }
    else
    {
        if (pushMessageGetter != null && this.pushService.IsEnabled())
            await this.pushService.SendPush(await pushMessageGetter(), new string[] { accountId.ToString() });
    }
}

I.e. if a client is connected, it sends an RPC to all his active devices. Else it sends a push message.
IsConnected is the method I'd like to get rid of, and my earlier suggestion was something in the lines of:

var clientInterface = this.connectionHub.Clients.Group(accountId.ToString());
bool hadConnections = await RPCCallAction(clientInterface); // the status of this would trickle back here!
if (!hadConnections)
    // send push here

You said I could use an error status for this which I'd be very happy to do, but how?

There will be no error if no call is made here:

var clientInterface = this.connectionHub.Clients.Group(accountId.ToString());
await RPCCallAction(clientInterface);

So how could I catch this as an error?

Thank you again!!

I just can't understand why awaiting an RPC can't return the status information, or why it can't be added.

But if it can't be added for any reason I'd be more than happy to catch "nothing was sent" errors and handle that as an offline case as you suggested. But calling an RPC on an empty IClient doesn't raise an error, so I don't understand how I could do that? I'm very very happy if this can be done!

If anyone is interested, IsConnected is currently implemented as such:

Every node uses an IMemoryCache for the case where the same node also serves the destination connected. If not it calls the Azure SignalR service's $"groups/{accountId}" endpoint, which returns 404 if no connections exist.
This is extremely inefficient though as I have to make a call every time an RPC is sent, instead of the API just returning that information!

I also keep connection ids in an IDistributedCache (Azure Redis), so I can disconnect any client on any node when needed.
But this leads to tons and tons and tons of problems to keep them in sync when stuff is rebooted etc.

I just can't understand why awaiting an RPC can't return the status information, or why it can't be added.

As I mentioned, there's an issue to enable this feature when sending to specific clients #5280. It's not currently on track to be implemented for .NET 6 either. It's non trivial to implement acks like this but its highly requested and we may spend some time figuring out all of the pieces. Then you could build something that used this new feature and tried to send a message to all clients for a specific user and decide if you should send a push notification instead.

Right now, you need to store presence information (as mentioned above) and optimistically do it.

Making the RPC wait for a reply from the client would slow down every operation and is even trickier when the ACK needs to work across a server farm.

This conversation has veered far from the original topic so I'd suggest piling onto that issue specified.

I just can't understand why awaiting an RPC can't return the status information, or why it can't be added.

As I mentioned, there's an issue to enable this feature when sending to specific clients #5280. It's not currently on track to be implemented for .NET 6 either. It's non trivial to implement acks like this but its highly requested and we may spend some time figuring out all of the pieces. Then you could build something that used this new feature and tried to send a message to all clients for a specific user and decide if you should send a push notification instead.

Right now, you need to store presence information (as mentioned above) and optimistically do it.

Making the RPC wait for a reply from the client would slow down every operation and is even trickier when the ACK needs to work across a server farm.

This conversation has veered far from the original topic so I'd suggest piling onto that issue specified.

Fair enough.

As a last thing, could you please just let me know how to implement
"Maybe you can use a failure to retrieve the result as the way to detect the offlineness."?

I loved that suggestion but I don't see any errors happening anywhere. So how would I achieve what you suggested?

Thank you!

"Maybe you can use a failure to retrieve the result as the way to detect the offlineness."?

While that's a separate issue, I don't think we'd add the API for this scenario. If you choose to use it for that, that's great, but the purpose of that issue is to return results from the client, not to detect if that client is online. Maybe you can use a failure to retrieve the result as the way to detect the offlineness.

It was part of that paragraph meaning that's how you could use the client ACK feature to implement the semantics you want. The feature doesn't exist.

"Maybe you can use a failure to retrieve the result as the way to detect the offlineness."?

While that's a separate issue, I don't think we'd add the API for this scenario. If you choose to use it for that, that's great, but the purpose of that issue is to return results from the client, not to detect if that client is online. Maybe you can use a failure to retrieve the result as the way to detect the offlineness.

It was part of that paragraph meaning that's how you could use the client ACK feature to implement the semantics you want. The feature doesn't exist.

Thank you for the clarification, I thought you meant I could use it as an alternative until ACK is implemented.
Oh well.

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!

I have too many other things to try to work on besides opening a new issue for this, but I'm still interested in having inbuilt support for disconnecting a specific client for security reasons (leaving clients without valid accounts connected leaks information they should no longer have access to).