Notify when new client

[hvolmer]

Question: I have custom SSE services running, but I am unable to identify when a new client request comes in. Is there a way to be notified when a ServerSentEventsService receives a new client or even better, to use a normal controller to handle the incoming connection and spin up a service as it's needed.

Thank you for your work.

[tpeczek]

In general using a controller here (although possible) would not be advised. In case of SSE the request is alive as long as client is connected so the action would have to "hang" till the client disconnects. Also there is only one instance of ServerSentEventsService per endpoint (it's a singleton). In general in ASP.NET Core architecture the MVC part is quite late in the pipeline and aims at handling typical request/response flows.

What could be done quite easily is adding overridable methods which would represent client connection and disconnection (similar to OnReconnectAsync). It would look something like this:

Task OnConnectAsync(IServerSentEventsClient client);

Task OnDisconnectAsync(IServerSentEventsClient client);

The question is would this API be sufficient for your use case.

[hvolmer]

Because I am fairly new to ASP (coming from node) and modern C# (I’ve been stuck in 3.5 CF for specific projects for years now) I will ask: Would a simple event or two be enough? I’ll clone the repo and look at your suggestions. Thanks From: Tomasz Pęczek [mailto:notifications@github.com] Sent: Thursday, November 9, 2017 3:32 AM To: tpeczek/Lib.AspNetCore.ServerSentEvents <Lib.AspNetCore.ServerSentEvents@noreply.github.com> Cc: Heath Volmer <hvolmer@pepperdash.com>; Author <author@noreply.github.com> Subject: Re: [tpeczek/Lib.AspNetCore.ServerSentEvents] Notify when new client (#8) In general using a controller here (although possible) would not be advised. In case of SSE the request is alive as long as client is connected so the action would have to "hang" till the client disconnects. Also there is only one instance of ServerSentEventsService per endpoint (it's a singleton). In general in ASP.NET Core architecture the MVC part is quite late in the pipeline and aims at handling typical request/response flows. What could be done quite easily is adding overridable methods which would represent client connection and disconnection (similar to OnReconnectAsync). It would look something like this: Task OnConnectAsync(IServerSentEventsClient client); Task OnDisconnectAsync(IServerSentEventsClient client); The question is would this API be sufficient for your use case. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#8 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AE0g40A9cM1wZ2qEnMxZYXIR6kpLK54Jks5s0tSXgaJpZM4QXKo5>.

[tpeczek]

@hvolmer in such case welcome to the community ;)

Yes events might be a good approach as well. Probably the best solution would be combining both (the base implementations of methods would trigger the events which leaves all options open).

We should discuss further your use case either here or through email (also feel free to reach out with any other questions you might have). I'll be more then happy to add this API (in general enough form) to the lib.

[hvolmer]

If you prefer direct email, that’s good too. I can’t see how to do that without posting an address in this support forum. For now, I’ve added a couple events down in the SSEService class. Pardon my poor enum naming… Seems to work. I will need to inject this into a singleton service to help navigate between various controllers and another SSE service. internal void AddClient(ServerSentEventsClient client) { var success = _clients.TryAdd(client.Id, client); if(success) { var handler = ClientChange; if(handler != null) { handler(this, new ServerSentEventsClientChangeArgs { Client = client, State = eServerSentEventsClientAddRemove.Added }); } } } internal void RemoveClient(ServerSentEventsClient client) { client.IsConnected = false; var success = _clients.TryRemove(client.Id, out client); if (success) { var handler = ClientChange; if (handler != null) { handler(this, new ServerSentEventsClientChangeArgs { Client = client, State = eServerSentEventsClientAddRemove.Removed }); } } }

[tpeczek]

I definitely prefer to have dedicated events, something more like:

event EventHandler<ServerSentEventsClientConnectedArgs> ClientConnected;

event EventHandler<ServerSentEventsClientDisconnectedArgs> ClientDisconnected;

My biggest struggle is around handling the reconnects. Those can be either handled by separated event or a joined one. Also need to handle reconnects probably moves the event triggering code down to the middleware (this is where those overridable methods might become handy).

I should have some time tonight so I'll create branch and push a proposal.

[tpeczek]

@hvolmer please check the client-connectivity-events branch and let me know if this would be good API for you.

[hvolmer]

Unfortunately, we just stopped this development path for now and I won’t be able to get anything useful done with it. I GREATLY appreciate your responsiveness, and if we pick this up again, I’m sure I will be following up. Thank you. From: Tomasz Pęczek [mailto:notifications@github.com] Sent: Friday, November 10, 2017 2:12 PM To: tpeczek/Lib.AspNetCore.ServerSentEvents <Lib.AspNetCore.ServerSentEvents@noreply.github.com> Cc: Heath Volmer <hvolmer@pepperdash.com>; Mention <mention@noreply.github.com> Subject: Re: [tpeczek/Lib.AspNetCore.ServerSentEvents] Notify when new client (#8) @hvolmer<https://github.com/hvolmer> please check the client-connectivity-events branch and let me know if this would be good API for you. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#8 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AE0g49lI9a0SIX2Y6kNS0fcB7ISS41urks5s1LwSgaJpZM4QXKo5>.

[tpeczek]

Lowering priority till a need for this API arises.

[manureini]

Hello ;)
I'm working on an website which is using these events.
They're working, but the User Property of the client is not the correct user for me.

serverSentEventsService.ClientConnected += (s, e) =>
{
     ClaimsPrincipal user = e.Client.User;
};

The user is now a user object, but is not the logged in user.

Is this maybe a issue of the ServerSentEvents in general?

[tpeczek]

Hi @lordmampf,

It seems likely that the issue is general, although I'm not able to reproduce it with the projects I have. Would it be possible for you to create a simple project which reproduces the issue and share it with me?

And in context of the events, can you share some feedback? I would love to integrate this functionality into main branch but first I must know it gets the job done.

[manureini]

Hello ;)

The Projekt is pretty complicated and I can not give it to you =(

But I solved this issue by adding a token to the Url.
var source = new EventSource('/sse?id=1&token=1234');

I've added a HttpConext parameter to read the query string inside the event.

I think the events are working fine and I can't find any problems from architectural point of view.