I want to implement a feature like, if anything has been updated on Server-side like in database(the change can be from a client or another resource), then an event should be triggered and i come to know what change has been made. Then, through a rest api, i will send the response to UI with an event code, message and the new data from database.
And on UI, i have the approach to handle the events.
Please, tell me the approach or study material to implement this feature.
To use bi-directional communication between the clients and server you can use one of the following frameworks depending on your requirments:
SignalR
WebAPI and WebSockets
Socket IO (framework for Node.js)
Alchemy-Websockets
Fleck
SocketCluster (framework for Node.js)
Related
so I'm in a little project of mine and for now the client gets some information it needs using requests, more precisely requesting the data to a nodejs server running express. The thing is I want that when 1 client alters something every connected client gets a notification that something just changed. How could I do this? I'm new to all this networking stuff so any help is appreciated.
Also the client is a C# Windows Forms
This sounds like it can be achieved via the publisher-subscriber design pattern. Where each client will subscribe to an event and listen to it (perform an action on it) whenever there's an event being broadcasted. I suggest you take a look at the pattern and see how others have implemented it particularly to your situation.
You can take a look at Socket.io which is "a library that enables real-time, bidirectional and event-based communication between the browser and the server."
I'm trying to create a tool for the QA team.
One of the features I'd like to add is a webhook for some events (sent as JSONs when some actions are taken).
AFAIK, in C# .NET Core v2.2, this feature is mostly implemented using the HttpListener class.
What I'd like to do is to run my simple Listener class/function in a parallel thread to the main program so events can be processed while the rest of the solution is active (it serves as an API to query DB).
My question is how to implement this.
my question mainly focus on how to run the listener on a background thread during app start - not on implementation of the connection.
The "Startup" is where I'd try to add it but I'm not sure how.
I found the services part (AddService, AddSingleton...) But couldn't find anything specific. Am I on the right track?
I didn't paste any code as the implementation is irrelevant (I guess) but will upload the Listener should anyone ask.
Is this existing in a Web app, or a Console App?
You might have a much easier time piggybacking on SignalR if you want to send Server->Client style events in json
https://learn.microsoft.com/en-us/aspnet/core/signalr/introduction?view=aspnetcore-5.0
Pretty easy to setup and get running, you can have clients subscribe to listen to an API end point and then bind to events to fire off functions when they get pinged from the server.
I am using C# ASP.NET MVC 4 Razor
I have a Grid in ASP.NET MVC Razor View that displays the user records. Is there any way to show the new users in Grid without sending the async request to server after each 1 min ?
I searched on Google a lot. Now, finally I am posting the query here to get any clue for this solution to avoid Traffic on Server. As this page will be visible to at least 20,000 users
#Christos approach is the right one!, Just to add more info about it for an ASP.NET solution I would it use SignalR, that lets you implement a simple server/client communication and it's cross browser (it has several polyfills that if it cannot use web sockets it will use server-sent event, and so on), and the best part is that you don't need to worry about that implementation.
Once your clients are connected to the signalR server you can notify them everytime you need to add a new item to the grid.
http://www.asp.net/signalr/overview/getting-started/tutorial-server-broadcast-with-signalr
I hope it helps!
You could make use of the the publish/subscriber pattern. This can be done using for instance a redis server.
In software architecture, publish–subscribe is a messaging pattern
where senders of messages, called publishers, do not program the
messages to be sent directly to specific receivers, called
subscribers. Instead, published messages are characterized into
classes, without knowledge of what, if any, subscribers there may be.
Similarly, subscribers express interest in one or more classes, and
only receive messages that are of interest, without knowledge of what,
if any, publishers there are.
Please have a look here.
Doing so, the first time a client requests data from the server will subscribe to the server for taking any updates. Once any update arrives, the server will push the update to the clients that have subscribed, without requiring from the client to make any other request to the server.
As for implementation details, please have a look here.
In a previous solution, I recall setting up code-behind-type hub connections for unit testing. I believe I used code from the previous SignalR Hubs C# Client GitHub wiki.
In the SignalR Hubs API guide there is an example of using a console-based client:
stockTickerHubProxyProxy.On("Notify", () => Console.WriteLine("Notified!"));
In an upcoming application there will be notifications to be pushed to several clients. Some of these clients will be UI-based (JS), and others, will be some back-end code that will perform some task.
I am familiar with the JS-based client connectivity. My question centers around attaching code-behind-type clients, and how their methods "notified".
I understand that with a UI-based client, the mechanism is to push the update to the client through dynamic invocations to client-side "methods". Since it's been a few months since I've touched SignalR, what is the best way to accomplish this where there is no UI involved?
To verify that I am understanding the documentation correctly , when valid transport method is used, a C#-based (non UI/JS) client is notified (push) through the SignalR framework - no client polling required?
The essential mechanism is the same for JS and C# clients. The solution is exactly what you mentioned in your question. The 'On' method will subscribe the client to any "notify event" triggered by the server. You can refer to the documentation to get a better understanding:
http://www.asp.net/signalr
I'm trying to use WCF to implement a comet style server push to an ajax web application.
In my WCF service, I've implemented a WaitForEvents method that calls Monitor.Wait to suspend the thread until new data arrives. At that point, the Monitor is pulsed, and the method returns the new data which closes the comet style request.
The request is made again when this happens.
Currently, this works fine but I noticed that WCF needs to create a new thread for each connected user. This is probably because the thread cannot be returned to the threadpool until data comes in, and so each connected user requires a new thread.
I want to make this implementation more efficient by having one thread service multiple connections. If I were to use a socket, this could be done by leaving the socket open and returning the thread to the thread pool first. When new data arrives, it will be delivered by another thread and we can write the new data directly to the socket and close it.
Does anybody know how this can be done via WCF?
I have been looking at "Push-Style Streaming" http://msdn.microsoft.com/en-us/library/bb472551.aspx and they mention that "WCF implements a "pull" model in which the application code (the service) returns an instance of Stream and relies on the lower-level infrastructure to pull data from this stream and write it out to the network." but I cant find any examples of this one the website.
Many thanks in advance!
Check out nComet
It's not using WCF, but I believe the author is working on a version that uses WCF. Contact him via codeplex and ask him :-)
"nComet is a .NET implementation of
the Comet (reverse-AJAX push)
architecture. This server-side
pipeline uses long-lived
client-initiated HTTP connections to
push messages to the client. Once the
client receives a response, it
immediately opens another HTTP
request, which the server holds until
a message is ready. This architecture
allows the server to push dynamic
html/xml/json/etc to the browser,
rather than the browser polling the
server.
This project is scoped to the .NET
server-side architecture, initially
providing a HttpListener (for a custom
host communicating with HTTP.SYS
directly) as well as a ASP.NET
implementation, where the ASP.NET
implementation can be hosted inside
IIS as well as an external process.
The library will simplify the
implementation of common message
patterns such as pushing the latest
data, as well as sync. Example code
and links to multiple client-side
javascript implementations will also
be provided."
You may also want to check out WebSync, a .NET comet implementation. Works just dandy with WCF.
(Disclaimer: I work for the company).