I am looking to build an online customer support system for one of our company sites and had a few queries with regards to the structuring.
The scenario is this. We would like users of our site to be able to click a "Live Chat Support" button, at which point they would get a popup that tries to connect them to one of our support team.
Our support team on the other hand, will be running desktop clients. Whenever a user on our site clicks the link, all of the desktop clients will "ring". Whenever a support team member "answers" the call, the other clients will stop ringing and that member will begin chatting with the web user.
Given that our desktop client will be made using WPF in C#.NET and our site is ASP.NET MVC 2 - what would be the best way to establish communication between the two?
My initial thoughts were to have the web side store the chat in an SQL database and somehow "Ping" the relevent desktop client telling it to update its chat log. Similarly for the desktop to the web. But I am unsure how to go about implement this between two different platforms. If it were desktop client to desktop client I imagine it would much easier, but this is not the case.
Also, please bare in mind that I realise there are already commercial applications out there that do this. However, we require some bespoke functionality that goes beyond a simple chat - it is not worth going into the specifics but basically we must implement our own solution.
Any help is much appreciated.
Web technology is an inappropriate platform for implementing real-time interaction. It can be done, of course, but you will certainly have issues with scalability, responsiveness and development effort. I urge you to examine your requirements very carefully and consider whether it is at all possible to leverage a vendor product to accomplish what you want to do.
If you still want to strike out on your own, the main hurdle you will have to overcome is how to push messages to the browser. "Pinging" the browser from the server is impossible using pure web technologies, because HTTP is built on a "pull-only" request/response model. There is no persistent connection maintained between the client in the server. After the server has finished sending the page to the broswer, the connection is gone.
You could poll the web server for new messages, but this is not a scalable solution. If you're only dealing with a very small (say single digits) number of users, then this might work, but your responsiveness will be limited by the speed at which you poll, and the faster you poll, the less scalable this solution will be.
A better solution would be to use Silverlight, Flash, or some other thick-client technology running in the browser. Then you could implement a service that handles message routing between clients. This article on CodeProject might be a good place to start.
Related
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth. Almost all the examples or information I have found are about using web sockets for Client/Server Side communication. I am having trouble figuring out how to set this up. I have considered using WebSocketHost as apart of Microsoft.ServiceModel.WebSockets, but then I am unsure how to bind it to a local port and not a URL.
Does any one have any suggestions
Thanks
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth.
You can open sockets on both machines using WebSockets as you found. The examples mention clients and servers because this is the typical usage, however the API really doesn't care. As long as each side has a listener and a sender they can communicate.
However I would like to mention that this isn't as simple as it sounds because both machines aren't always available. Sometimes one or the other is busy or the network is blocked or something else is going on, or the listener is too busy to respond right away, so you're going to end up needing some sort of queuing on both sides.
If you're doing a process based operation where one side tells the other "I want X" and it's a big operation like producing a document, I've found it much more resilient to build a queue in a database and toss the request in there, then wait for the other side to update the record to say it's done.
If they're smaller, faster requests, MSMQ would be more appropriate if you have it available.
However back to your original question, if you want to use it, any of the client-server examples should work just fine. The API doesn't care.
You can use SignalR Self-Host you really don't want to create your own WebSockets framework since this this will take a long time.
Here is a link on how to start a OWIN server in Windows services.
Hosting WebAPI using OWIN in a windows service
And how to set signalR in self host
Tutorial: SignalR Self-Host
You can accomplish this with Memory Mapped Files.
Inter-Process Communication with Memory-Mapped Files
I have a web service which is completely build using .net C#. Now I want to use either signalR or Node JS so that if web service has some update it can push it to client which is in html javascript.
Design Consideration:
I am running my web service on IIS.
Client in Html javascript
Number of user may be high. May be 100 or 200
There will be frequent updates for long period of time from web service.
Web service does DB call and little calculation
Server specification is not an issue.
Need stability and security in the web service
If you are already using the Microsoft stack (.NET, C#, IIS) on your back end then it would make sense to use SignalR because it will integrate nicely with your existing stack.
You already have development experience in C#, do you have experience in NodeJS too? If not then that's a big point to consider as there will be a learning period where you become accustomed to the Node way of programming javascript.
100-200 users isn't that many for either NodeJS or SignalR. SignalR uses some of the async features of .NET and so a thread won't be used by an open connection until something is ready to happen (e.g you might be waiting on DB IO). Similarly, all IO in node should be done asynchronously.
If you're using SQL server then you might find using SignalR opens up other possibilities, e.g using Entity Framework to improve productivity and get your product to market faster.
As for stability and security, those are often dependent on the way you design, write and configure your application rather than the technology stack itself.
Edit: A couple of resources for getting started in the respective technologies that I've found helpful in the past:
SignalR
NodeJS
I want to create a cross platform chat app with backend in c#
I searched for an approach to do so and found that I can do so with http requests to handlers on my server and use the response accordingly.
So till now I made the handlers which can add users, login, send and receive messages using database for storage.
Now I am making android client for that and to get messages for user I need to do http requests at a specific interval (3 seconds).
I feel it is not a good approach to do this. I am making this app for a target audience of nearly 30000. They would be able to chat one on one at a single session.
I just want to know if I am going in right direction or There is far more better ways to make chat apps using backend.
I have heard about wcf but I am not clear with what approach should I take. Please guide me about approaches for chat application.
Edit
An example of little working of any famous chat app like whats app, facebook messenger would be a great help.
Thanks.
You could do it with HTTP, but I'd suggest using TCP instead. There's a very solid base for a C# based TCP server on codereview right here which will outline how to deal with Socket objects how to handle connections properly.
The main perk of going about it this way is that you can connect your client to the server, and the client can be virtually any language, it doesn't have to be C# - as long as the language supports sockets, you'll be fine.
On top of that you can have the client listen to the server, which removes the need of polling the server for new messages every couple of seconds; the client socket will receive data when the server sends it, and you can handle it right away, nearly in real-time, whereas if you'd poll the server for new messages over HTTP every - say 3 seconds - you'll always end up with a delay in your chat service, which is something I think you will want to avoid.
See the code sample on CodeReview I linked above, and read up on how Sockets work in C#, how TCP works in terms of guarantees (TCP guarantees that whatever is sent over it will end up on the other side in the same order, but not necessarily in one packet, etc) and I'm pretty confident you'll be able to make a excellent chat app if you put it all to good use.
Edit: I just noticed the WCF tag on your post. I'd personally steer clear of it for this specific project since you want to achieve cross-platform support; try going as low-level as you possibly can for that.
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 have 50+ kiosk style computers that I want to be able to get a status update, from a single computer, on demand as opposed to an interval. These computers are on a LAN in respect to the computer requesting the status.
I researched WCF however it looks like I'll need IIS installed and I would rather not install IIS on 50+ Windows XP boxes -- so I think that eliminates using a webservice unless it's possible to have a WinForm host a webservice?
I also researched using System.Net.Sockets and even got a barely functional prototype going however I feel I'm not skilled enough to make it a solid and reliable system. Given this path, I would need to learn more about socket programming and threading.
These boxes are running .NET 3.5 SP1, so I have complete flexibility in the .NET version however I'd like to stick to C#.
What is the best way to implement this? Should I just bite the bullet and learn Sockets more or does .NET have a better way of handling this?
edit:
I was going to go with a two way communication until I realized that all I needed was a one way communication.
edit 2:
I was avoiding the traditional server/client and going with an inverse because I wanted to avoid consuming too much bandwidth and wasn't sure what kind of overhead I was talking about. I was also hoping to have more control of the individual kiosks. After looking at it, I think I can still have that with WCF and connect by IP (which I wasn't aware I could connect by IP, I was thinking I would have to add 50 webservices or something).
WCF does not have to be hosted within IIS, it can be hosted within your Winform, as a console application or as windows service.
You can have each computer host its service within the winform, and write a program in your own computer to call each computer's service to get the status information.
Another way of doing it is to host one service in your own computer, and make the 50+ computers to call the service once their status were updated, you can use a database for the service to persist the status data of each node within the network. This option is easier to maintain and scalable.
P.S.
WCF aims to replace .net remoting, the alternatives can be net.tcp binding or net.pipe
Unless you have plans to scale this to several thousand clients I don't think WCF performance will even be a fringe issue. You can easily host WCF services from windows services or Winforms applications, and you'll find getting something working with WCF will be fairly simple once you get the key concepts.
I've deployed something similar with around 100-150 clients with great success.
There's plenty of resources out on the web to get you started - here's one to get you going:
http://msdn.microsoft.com/en-us/library/aa480190.aspx
Whether you use a web service or WCF on your central server, you only need to install and configure IIS on the server (and not on the 50+ clients).
What you're trying to do is a little unclear from the question, but if the clients need to call the server (to get a server status, for example), then they just call a method on the webservice running on the server.
If instead you need to have the server call the clients from time to time, then you'll need to have each client call a sign-in method on the server webservice each time the client starts up. The sign-in method would take a delegate method from the client as a parameter. The server would then call this delegate when it needed information from the client.
Setting up each client with its own web service would represent an inversion of the traditional (one server, multiple clients) client/server architecture, and as you've already noted this would be impractical.
Do not use remoting.
If you want robustness and scalability you end up ruling out everything but what are essentially stateless remote procedure calls. Since this is exactly the capability of web services, and web services are simpler and easier to build, remoting is an essentially pointless technology.
Callbacks with remote delegates are on the performance/reliability forbidden list, so if you were thinking of using remoting for that, think again.
Use web services.
I know you don't want to be polling, but I don't think you need to. Since you say all your units are on a single network segment then I suggest UDP for broadcast change notifications, essentially setting a dirty flag, and allowing the application to (re-)fetch on demand. It's still not reliable but it's easy and very fast because it's broadcast.
As others have said you don't need IIS, you can self-host. See ServiceHost class for details on how to do this.
I'd suggest using .NET Remoting. It's quite easy to implement and doesn't require anything else.
For me its is better to learn networking.. or the manual way of socket communication.. web services are mush slower because it contains metadata..
your clients and the servers can transform to multithreaded application. just imitate the request and response architecture. it is much easy to implement a network application like this..
If you just need a status update, you can use much simpler solution, such as simple tcp server/client messaging or like orrsella said, remoting. WCF is kinda overkill here.
One note though, if all your 50+ kiosk is connected via internet, then you might need use VPN or have an open port on each kiosk(which is a security risk) so that your server can retrieve status update from each kiosk.
We had a similiar situation, but the status is send to our server periodically, so we only have 1 port to protect/secure. The frequency of the update is configurable as to accomodate slower clients.
As someone who implemented something like this with over 500+ clients and growing:
Message Queing is the way to go.
We have gone from an internal developed TCP server and client to WCF polling and ended up with Message queing. It's the only guaranteed way to get data to and from clients and servers over the internet. As a bonus, many of these solutions have an extensive framework makeing it trivial to implement publish-subscribe, Send-one-way, point-to-point sending, Request-reply. Some of these are possible with WCF but it will involve crying, shouting, whimpering and long nights not to mention gallons of coffee.
A couple of important remarks:
Letting a process poll the clients instead of the other way around = Bad idea.. it is not scalable at all and you will soon be running in to trouble when the process is take too long to complete.. Not to mention having to handle all the ip addresses ( do you have access to all clients on the required ports ? What happpens when the ip changes etc..)
what we have done: The clients sends status updates to a central message queue on a regular interval ( you can easily implement live updates in the UI), it also listens on it's own queue for a GetStatusRequest message. if it receives this, it answers ( has a timeout).. this way, we can see overal status of all clients at all times and get a specific status of a specific client when needed.
Concerning bandwidth: kiosk usually show images/video etc.. 1Kb or less status messages will not be the big overhead.
I CANNOT stress enough that the current design you present will have a very intensive development cycle AND will not scale or extend well ( trust me, we have learned this lesson). Next to this, building a good client/server protocol for this type of stuff is a hard job that will be totally useless afterwards if you make a design error ( migrating a protocol is not easy)
We have built our solution ontop of ActiveMQ ( using NMS library c#) and are currently extending Simple Service Bus for our internal workings.
We only use WCF for the communication between our winforms app and the centralized service(s)