I am about to develop an application, in which the windows application will receive messages from the server when there is a new entry in server database. I am planning to do the same using xmpp and c# in asp.net. Is that a better way?
The scenerio is like this: Whenever a new entry is inserted into my sqlserver database, my windows application should be notified with that new entry. i.e. I want to push the message from the server to the windows application. How can I push the message using xmpp? Can I set the server as my company server? Or should I have to use jabber server itself?
Assuming there are multiple instances of the client running, then using some form of pubsub, like XMPP pubsub would be an appropriate solution. There are many pubsub solutions available, you will have to select the appropriate one based on all your requirements and/or restrictions.
If this functionality is considered business critical, then you should definitely be using your own server.
I don't know if any of the public XMPP servers have pubsub enabled and configurable by the public or not.
Related
I've a winform app that is connected to a sql server database and there are many pc client with the application installed. A standard desktop client/server application.
I want that a single client can communicate with all others, for example I want the administrator cand send a message to all clients. Something like SignalR fir asp.net.
I do not want that is the client that ask to database if there are messages, I want that all clients connects to a service that raise events like broadcast message or chat.
I prefer not to install something that needs a web server, but I will consider all your suggestions. Also I'd like to know if there is a specific name to this functionality so I can do a more accurate search.
thanks to all
Currently we have windows desktop software that is installed at customer premises and the software is polling a WCF service every 10 mins for updates on data.
I wanted to change this a real-time so when there is a update on server it pushes data back to the desktop client or web client.
The desktop client may be offline i.e. PC can be switch off or application is not started. In this scenario we would like to messages or updates to be queued
As we only support windows desktop client application so I will be using .Net technology.
This is the architecture that I thought of, please let me know if there is a better way to achieve.
NServicebus is another excellant tool for this type of thing.
Please consider streaming / queue platforms such as:
Tibco RV
Aleri
RabbitMQ
Consider Microsoft message queue: https://msdn.microsoft.com/en-us/library/ms978430.aspx
For offline case you don't need any queue. The app will check for update when started. When online, you can keep open TCP or UDP connection to server and send update notification to client. It will be something like "Update notification service".
Am developing client-server application for updating real time chart. Can anyone suggest me any framework/concepts for developing .Net based Server application (so that server will respond to clients very faster)
Client is not a web-based one (it will be MatLab client application). And each client will establish individual connection with server. Server needs to respond to individual client in real time.
I would look into signalR. It's a push framework that lets you maintain long running connections between client and server which enables the server to push updates to the client.
http://www.asp.net/signalr/overview/signalr-20/getting-started-with-signalr-20/tutorial-getting-started-with-signalr-20
SignalR is absolutely awesome here, and with OWIN you can host SignalR within a console app even. However, if you are not interested in learning a new framework, and are not using asp.net, you might want to use a regular Socket library provided with .NET and go from there.
I m developing a C# database application. I used SQL Server 2005 as back end and C# .NET 2010 as front end.
My application is installed on each client machine. When database is updated all clients of my system get notified By SQL Server Event Dependency technique.
But now I want to control the number of clients connected to server. That is I only want to give access to 3 clients. For that, I want to add some client/Server code in my application using socket programming.
Please guide me on this issue.
From the SqlDependency Class on MSDN:
SqlDependency was designed to be used in ASP.NET or middle-tier services where there is a relatively small number of servers having dependencies active against the database. It was not designed for use in client applications, where hundreds or thousands of client computers would have SqlDependency objects set up for a single database server. If you are developing an application where you need reliable sub-second notifications when data changes, review the sections Planning an Efficient Query Notifications Strategy and Alternatives to Query Notifications in the Planning for Notifications topic in SQL Server Books Online.
In your particular scenario, I guess it would be a good idea to have a middle layer server which manages the client machines and which will use the SQLDependency to be notified by the changes in the database. Then, it will push notifications to batches of n client machines, following the logic you expect.
I have the following architecture for a project I'm working on.
My question is how to begin implementing the TCP/IP responder part.
It's function, in case the diagram is hard to read, is to wait for a connection from the Order Viewing client, and subsequently notify said client of incoming orders.
I was thinking a queue, but unfortunately I don't know where something like this would fit in the VS2008 hierarchy of things.
If it's part of the ASP.NET web page, should I use the application start event to start the TCP IP responder?
It's not a web service, because those respond to http requests...
If I had to implement your "TCP responder" I'd probably implement it as a windows service and have both the ASP.NET app and the Winform client contact it (e.g. to avoid the problem of recycling of the ASP.NET etc.)
That said, I can think of gazillion easier ways to get the effect you want to achieve (getting the winform client to know about new orders) such as
Using Queues as you mentioned. Windows comes with MSMQ (you need to enable it in add windows features). Using MSMQ from C# is fairly easy. You can also use WCF if you like
exposing an http endpoint on the client and have the client notify the ASP.NET server where it is listening by calling one of its pages
write the orders to the DB and poll it from the client/use System.Data.SqlClient.SqlDependency to know when there's a change
Heck even writing the orders to a file on a shared folder with a FileSystemWatcher would work (though I'd probably wouldn't recommend that)
Why don't you use http? You already have the http server so you don't need any TCP responder - just do http polling at the client.
And if you don't want polling or have too many clients then you can use something like SignalR for notifications.