I'm currently designing a live analytic site using Asp.Net + C#, I was wondering what is the best method to transmit the data from the server to the client, here is what I've thought of so far;
Using Asp.Net AJAX UpdatePanel, and regularly update it with a timer
using JavaScript.
Create a server application (In C#, Java, Node.Js or Ruby) and use
Socket IO to retrieve a constant stream of data from it.
Create a JSON web service which returns large amounts of data, I
could use JQuery/AJAX to request it and process it in real-time on
the page.
Do any of these seem a good idea, or are their any other options?
I would never use the update panel, it would be too heavy for what your doing. Regular ajax calls would work just fine and write up a webApi service. Websockets would work well too, but is a little more complex. Depending on your time, you might want to check out SignalR which is a websocket client solution that can fall back to polling if the browser doesn't support websockets.
Related
i decided to write a card game with c# that has a winform application for main server to manage the game with a web interface. i chose SignalR self-host for main server. because i want to sell this app to others and dont want to modify the code or html of the web interface. so my question is: is that good for handling 10000 client request? is there a way to write this app for better performance?
another thing is i want to write the main server and login cashout profile and ... most written by customers like poker mavens and i just create a api with json to do this functions. plzzzz guide me which way is better to write this app!
With your server code self hosted and a javascript client calling into your server methods, becoming your browser based client, your design should work.
I am looking at this. https://learn.microsoft.com/en-us/aspnet/signalr/overview/deployment/tutorial-signalr-self-host
But I think you'll need to figure out scale out scenarios and server failure scenarios with the self host. In case there is a patch update on the server and it has to restart, you'll need to be able to get a backup. Also consider the case when you need to upgrade the server. So you'll need to be able to host it in multiple servers and you'll need to provide the signalr backplane option.
From a performance point of view, I have tested a web api signalR application on a single 4-core-14-GB server and was able to scale up to 20k connections, with the server comfortably serving more than 200 Requests per second.
With a backplane these numbers were around 100-150 rps.
The response times in both cases were very good ~ 500 ms.
Although please note that your numbers could be VASTLY different based on your actual functionality.
I want to consume the API messages in c#.net and the response it may come continuously/frequently. Team suggest me to use Web sockets. But I consume the API thru HTTP. Can any one give idea which is better and advantages of Web-socket in continuous receiving the messages as well as in HTTP
HTTP normally uses a request/response model. It does not allow the server to send data to the client, unless the client first requested it. This can be worked around by letting the client regularly poll the server, or by using the long polling technique where the server delays the response until data is available. In both cases, the client will need to regularly make a new request (though less often with long polling).
Web sockets remove these limitations so that polling or long polling is no longer needed.
You may try with ASP.NET SignalR which able to send and receive messages via HTTP. You can achieve real-time web functionality to your messaging application. It's able to have server code push content to connected clients instantly, rather than having the server wait for a client to request new data.
Have a look at these samples -> http://www.asp.net/signalr/overview/getting-started/tutorial-getting-started-with-signalr
I would like to have a client application and web application (or service, no UI) and I would like to connect to said web service from within my desktop application and to have two simultaneous network stream, one of them for uploading data and reading them on server and the other one for sending stuff to the client application.
I am not looking for a solution that uses anything more than that like WCF or anything, I just want a way to create connection between web server and my client application and exchange pure binary data. I would implement the protocol myself, I am not looking for any entities or encapsulation like WCF provides.
I don't even know what project type is the best choice here. I thought about empty ASP.NET application maybe that I'd upload on FTP but I have no idea what I should do next to make the application connectible to. I am not asking for complete solution of course, rather some articles that focus on how to make a plain and simple connection between server and client. I want server to be able to immediately update client and vice versa, that's why I am looking for a way to have stream.
Edit: I may as well say that the service is meant to be placed on ASP.NET hosting and I don't know how ports work on these, if there are any restrictions or anything.
"Web service" and "Network stream" are incompatible concepts. Web-services are (ideally) stateless and disconnected - so they work regardless of how the underlying network works. Messages are exchanged only from client-to-server and are encapsulated in HTTP request/response pairs. Hence "web service".
If you want to exchange "pure binary data" (as you put it) then you just need to work with sockets (or use .NET's TcpClient, which wraps up sockets in an easier-to-use API). ASP.NET would be inappropriate for this.
You can technically have an application that uses sockets that runs within an ASP.NET host process but this might not work depending on how security is set-up and it's also bound by the ASP.NET process lifecycle (so it is activated by IIS and can be shut-down or recycled at any time without warning).
You do not want to use ASP.NET Web Services for this (ASMX). That is a legacy technology, and should not be used for new development.
Why do you not want to use WCF? Do you believe it's too complicated? The thing about WCF is that it removes the complication of creating your own protocols.
Also, which version of .NET are you using? WCF get a lot easier to configure with .NET 4.0.
Here is simple duplex example using WCF.
Try it, check if performance you've got is enough, try to use alternative bindings ( like net.tcp). WCF is really neat tool to use. Once become more familiar with it you will love it.
Also check chapter on bindings in WCF from Learning WCF
Have a look at the MVC4 APIController. It works much like stock MVC except that methods return XML or JSON (or anything else you like).
Eg
/api/Users/Get
would could return something like
{
{"Username":"Bob", "Id":3},
{"Username":"Steve", "Id":4}
}
You can also return files and other streams by using special return types. You even get strongly typed, validated input through the use of models.
There's an example here which shows a full CRUD controller and sample AJAX calls from JS which you can replicate in your desktop app
What is a good strategy for implementing long polling in a .Net application.
Would it mean having a JS setInterval() based approach to keep polling the server for updates that can be rendered on the page. I have always thought that that could be a challenge when it comes to scalability as it seems it would generate a lot of extra requests to the web server. I have read that this type of functionality should be implemented using a non blocking web server (single threaded) NODE.js etc...
Since there's only one thread/event loop it seems like the requests would have to be very lightweight to service several requests in a timely fashion. Can Node.Js trigger db calls?
I have seen an online dating site where you receive notification in the form of a fad-in/fade-out popup when someone visits your profile when you're currently logged into the system. I am impressed that something like that can work so well for a high volume site.
Is it reasonable to assume that this type of notification system is implemented using long polling? Based on constantly polling through JS?
I am seeing similar behind the scenes updates her on the SO site as well (messages/votes etc) Does this use a similar strategy as well?
SignalR and pokein are two good options.
A blog post by scott hanselman which explains using SignalR
http://www.hanselman.com/blog/AsynchronousScalableWebApplicationsWithRealtimePersistentLongrunningConnectionsWithSignalR.aspx
Realtime web applications have been with us for quite some time now:
the history of Polling goes from setInterval Technique to HTML5 WebSockets.
Here you can find Simple Long Polling Example with JavaScript.
http://techoctave.com/c7/posts/60-simple-long-polling-example-with-javascript-and-jquery
I have a server client application.
The clients sends the server http posts with info every second or so.
The server is implemented using C#, there server doesn't need to respond in any way to the client.
Whats the easiest and most practical way to get this done? Is there some kind of library that is easy to use that I can import into my project.
Why not just use a regular old web service? It sounds like you have simple functionality that doesn't need to maintain a connection state. With a web service, you can simply expose the methods to your client, accessible via HTTP/S. If you're already using .NET for your client, you can simply add a web reference to your project and have .NET do the heavy lifting for you. There wouldn't be any need to reinvent the wheel.
You can use http.sys to create your own http listener without IIS or additional overhead. Aaron Skonnard has a good article here.
Because of certain limitations of uhttpsharp (specifically no support for POST forms and file uploads and it using threads to process requests), I've made NHttp available at github which supports full request parsing like ASP.net and processes requests using the asynchronous TCP model.