Developing a messaging application for web and mobile with real-time notification. Project flow is ..
Backend - DataBaseOperations and Services
Web
APi (for mobile app)
I need to send messages from the server to a user that can be connected from more than one location (web and mobile app).
Web and API works separately and access Backend. Please share suggestions what flow should I use to implement singalR in my project
This is a broad question, but I'll give enough to get you started in the right direction. Since you're going to be in load-balanced environment, you'll need to implement a backplane. This sits behind your web servers and aggregates the messaging. Here are some links that will guide you set up SignalR:
https://www.asp.net/signalr/overview/guide-to-the-api
https://www.asp.net/signalr/overview/guide-to-the-api/hubs-api-guide-javascript-client
https://www.asp.net/signalr/overview/performance/scaleout-in-signalr
Also, you'll need these nuget packages (minimum):
Microsoft.AspNet.SignalR.Redis or SqlServer
Microsoft.AspNet.SignalR
Microsoft.Owin
There is nothing really special in what you want to achieve.
Your client app needs to be authenticated before sending SignalR messages. That way you can identify a user and protect your server resources.
That´s the first part I would start looking into (there are tons of info about this matter if you google it).
Then you need to send a message from the server to a user and that user can have 2 client apps connected (web and mobile or even more, like other browser tabs). That can be achieved using SignalR groups.
A SignalR group is just a group of connections (not users) with a given name.
One common scenario is creating a group for each user, and that group will hold the connections of the user. This is a logical pseudo structure of how SignalR groups work (not actual code):
Group name: "johnUser"
Group connections: [
00001, // mobile app connection
00002, // brower tab connection
00003, // broswer tab connection 2
0000n // etc
]
Those numbers are simulations of Connection ids. SignalR creates them for you.
Then you just need to send a message to the group, and all connected clients will get it.
If you are just starting with SignalR I would not complicate things implenting a backpane unless you really need it and you know what you are doing. A single server can handle hundreds of concurrent connections and you can scale-out later if you want.
Regarding architecture, it´s not very clear what you mean by Web and API works separately. It´s better if you ask more specific questions after you actually try to code something.
Related
I have an API running on a Function App in Azure.
I want this API to only accept communications from two parties:
A blazor website
All copies of a piece of packaged software (a WPF application which will run on customer computers)
I want all other traffic to be rejected.
What is the best way to configure this networking scenario?
The ideal setup:
API should only be able to talk to the Blazor App as well as the client programs, not outside connections. The API can talk to the database which lays behind a virtual network. This Database VNET is already set up.
Any help is appreciated.
Use API Management in front of the API and require Ocp-Apim-Subscription-Key in the requests.
Also, add ip restrictions to avoid unauthorized access
I'm attempting to build a live support chat application in C# using a WCF microservice and after endless searches I still can't find the answer, hopefully someone here can point me in the right direction.
My problem is that rather than a typical chat room a where users broadcast messages to all connected clients, I need the application to be more like a Live Support app found on websites such as Amazon or eBay.
Ideally multiple customer support agents will have a pre installed WinForms chat application on their machines, when a customer opens a chat window (aspx page) it will connect to a server/service and the server/service will then call all connected customer support agents until one answers. At this point the customer and agent will be connected in a private chat window.
Could somebody please give me some insight or ideas on how to do this?
Thanks,
Owen
You can use ASP.NET SignalR which is a library for ASP.NET developers that makes developing real-time web functionality easy. SignalR allows bi-directional communication between server and client. Servers can now push content to connected clients instantly as it becomes available.
Here you can find more details and many tutorials about SignalR.
The first resoult in google
A WCF-WPF Chat Application
Video tutorial
WCF Chat Application
ASP.NET Chatting using WCF Services and JSon
A simple peer to peer chat application using WCF netPeerTcpBinding
usefull lectures
HTML 5 Web Sockets
Always first ask google, above you have few ready to use projects that you can copy to your solution
EDIT:
Also as tip I can recommend bi-directional message queues at application level, then make index for messages with session and users identifier. Next step would be WCF with pop and push logic based on wait objects. At low cost you will need to lock queue. WCF will do heavy job. Also problems can occure inside app with proxy management and message sending so dedicated proxy for chat would be great and safest idea. And read about Duplex Services that can be usefull here DUPLEX SERVICE
These are my findings, not checked though:
Live Support Chat using SignalR
Parle
A tutorial from ASP.NET team:
Real-time chat with SignalR 2
The first one looks very early development stage, Parle is somewhat more promising.
Anyway, since I continue my research on the topic maybe I'd need to augment my answer. Until then the links could be a good starting point.
I am building a social application and was wondering how facebook achieve their notifications.
As you know, facebooks notifications are instant. As soon as someone takes an action, people are notified.
I assume they don't have a query running on the database all the time.
Can someone point me in the right direction. Thanks
Since your question is tagged with C#, ASP.NET you should use the awesome SignalR library. Basically SignalR enables you to send push notifications to the clients. Which exact underlying technique it uses is influenced by the capabilities of the Server and the Client.
There is a big real time chat site called jabbR that is built on top of SignalR:
http://jabbr.net/
Here are some more links that should get you started.
Project site: http://signalr.net/
Hosted Code (Open Source): https://github.com/SignalR/SignalR
Wiki: https://github.com/SignalR/SignalR/wiki
Projects using it: https://github.com/SignalR/SignalR/wiki/Projects-Using-SignalR
Facebook uses a messaging protocol (which it designed) called Thrift. This allows notifications from clients to servers with very low latency. I would imagine updates on the server would be triggered depending on the user action and relevant users that are logged in would be notified by the same mechanism.
Using a messaging protocol such as thrift (also see Protocol buffers) clients don't have to poll the server for updates, instead the server can push notifications to clients. To do this the server needs to have a notion of who is logged in at any one time (Login, logout handshaking) and of them, who should receive notifications from a particular client action.
Easier said than done, especially when you have 800 million potential users logged in!
You might want to take a look at http://nodejs.org/ - it is an event-driven model which is perfectly ideal for a 'social network' / instant notifications scenario.
FYI: You also might find that using a non-SQL database such as MongoDB (http://www.mongodb.org/) will be a lot faster when querying from the DB since each 'person' object in a social network scenario has his/her own unique attributes - which in a normal SQL database is hard to design.
I am planning a SaaS system, to be written in C#, ASP.NET using WCF that has two separate components:
On a static IP web server in the cloud will be a web app, common to all clients.
Inside each client's office will be another app, installed on a server with IIS.
The site app will obviously be able to connect to the web services published on the web site. But here's the rub - I also want the web app to be able to initiate a connection to the site app... and the on-site server may not necessarily have a static IP. I can't control this, because we may have hundreds of clients at some point in the future, and we cannot limit our saleability by insisting that the customer has a server with fixed IP.
So, how to do this?
I could have the site apps "checking in" with the web every minute or so, to give the web app the possibility of responding with a "while you're here, please do x,y,z..." but that seems very inelegant. Also, if we're talking about hundreds of clients, I don't want to be bombarding my web server with all these "hi there!" messages if they're not actually required.
Is there a better way?
WCF? Here we go:
Use a message based approach (exchange message, no stateful method calls).
Clients connect to the server. Establish a HTTP-based TWO WAY CONNECTION. This way the server can call back to connected clients. This is standard WCF stuff and works well through NAT with version 4 of the .NET framework.
Voila. In case of a disconnect the client can re-connect, re-identify himself and gets the pending messages.
IIRC "push communication" is done by letting the client do a HTTP Request with an indefinate timeout. Then the server responds when he has something to say. After the respons the client immediately makes a new request.
It works out the same way like the server is making the connection and takes far less resources than polling.
Dynamic DNS is one possibility, but depends on your clients/customers.
If the site app is created by you, it only has to contact the web server when its address has changed (or when the site server/web app is restarted). Still, a keep-alive heart beat of, say, every 30 min. to 1 hour isn't a bad idea.
Edit: I think SNMP services may provide the answer but I'm not a networking expert. You'll have to do some digging or ask a separate question on stackoverflow.
What would you say about Comet technology?
Sounds like you'll definitely need some sort of registry on the server, then it could attempt to call out to the client apps if it needs work doing.
Generally it is client apps that check in with the server every X seconds - this is how Selenium grid works anyway. With a central hub with which clients register. When the hub receives a request to run some tests it passes the jobs out to the clients to perform.
You may not need the "checking in". The server could just attempt to call out to a registered client app until it finds one that is available.This way only the server would need a static address (could use a DNS name instead of an IP to make it more robust).
Also have a look at XMPP PubSub. This could be a more robust and standardised way to handle this.
In the end I decided to go with NetTcpBinding, for reasons best given by #Allon Guralnek here. It's worth clicking through and reading what he has to say...
I'm working with an n-Tier application using WinForm and WCF
Engine Service (Windows Service) => WCF Service => Windows Form Client Application
The problem is that the WinForm Client Application need to be 100% available for work even if Engine Service is down.
So how can I make a disconnected architecture in order to make my winform application always available ?
Thanks.
Typically you implement a queue that's internal to your application.
The queue will forward the requests to the web service. In the event the web service is down, it stays queued. The queue mechanism should check every so often to see if the web service is alive, and when it is then forward everything it has stored up.
Alternatively, you can go direct to the web service, then simply post it to the queue in the event of initial failure. However, the queue will still need to check on the web service every so often.
EDIT:
Just to clarify, yes all of the business logic would need to be available client side. Otherwise you would need to provide a "verify" mechanism when the client connects back up.
However, this isn't a bad thing. As you should be placing the business logic in it's own assembly(ies) anyway.
Have a look at Smart Client Factory: http://msdn.microsoft.com/en-us/library/aa480482.aspx
Just to highlight the goals (this is sniped from the above link):
They have a rich user interface that
takes advantage of the power of the
Microsoft Windows desktop.
They connect to multiple back-end
systems to exchange data with them.
They present information coming from
multiple and diverse sources through
an integrated user interface, so the
data looks like it came from one
back-end system.
They take advantage of local storage
and processing resources to enable
operation during periods of no
network connectivity or intermittent
network connectivity.
They are easily deployed and
configured.
Edit
I'm going ansewr this with the usual CYA statement of it really depends. Let me give you some examples. Take an application which will watch the filesystem for files to be generated in any number of different formats (DB2, Flatfile, xml). The application will then import the files, displaying to the user a unified view of the document. And allow him to place e-commerce orders.
In this app, you could choose to detect the files zip them up and upload to the server do the transforms (applying business logic like normalization of data etc). But then what happens if the internet connection is down. Now the user has to wait for his connection before he can place his e-Commerce order.
A better solution would be to run the business rules in the client transforming the files. Now let's say, you had some business logic which would based on the order determine additional rules such as a salesman to route it to or pricing discounts...These might make sense to sit on the server.
The question you will need to ask is what functionality do I need to make my application function when the server is not there. Anything thing which falls within this category will need to be client side.
I've also never used Click Once deployment we had to roll our own updater which is a tale for another thread, but you should be able to send down updates preety easily. You could also code your business logic in an assembly, that you load from a URL, so while it runs client side it can be updated easily.
You can do all your processing off line, and use some thing like Microsoft Sync Framework to sync the data between the client and the server.
Assuming both server and client are .net, you can use same code base to do the data validation both on the server and the client. This way you will have a single code base that will serve both server and client.
You can use frameworks like CSLA.NET to simplify this validation process.