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.
Related
I'm trying to get my head around this...
I have an application composed of one Server(basically a N tier console application with TCP Async socket programming in C#), One MSSQL database and several clients.
Now the problem is thousands of clients is connecting to this server at the same time and server is not responding efficiently.I want to make this server as distributed and scalable to distribute the clients load.
I'm trying to figure out if there's solution to this problem.Any convenient solution is highly appreciable.
Thanks in advance...
You are a but slim on details, and this is not a drop-in solution: but I always steer clear of load balancers ( central point of failure, and you can only efficiently use the one datacenter or region ).
The client is the load balancer
instead, have a central endpoint to list the farmed servers, and then have the client randomly select a server to use for an amount of time. That selected server can then specialise on serving resources for that client, copying data from remote server(s) locally, if not already.
This selected server would be the master for that client, data would be created there and replicated to other servers later if the client changes server.
With such a distributed setup your servers can be deployed anywhere in the world generically. So your clients also get better latency and you can find the best priced hosting without being tied to a load balancer.
Container Clustering
You'll find clustering like coreos interesting but much more complicated to setup. But don't rule it out. For such a simple console application, it's not that hard to tweak your solution and control your own simpler scalable infrastructure with no extra layers of obscurity.
I would make the server-application cluster able, so that you can start instances multiple times on different virtural or physical computer. Than i would chose one single computer to be a load balancer. A good tool for load balancing in your case is HAproxy. This proxy will balance the load of work on different server. This will bring you the optimum of performance.
I've a problem with a multithreading app in C# and I would appreciate some help, since I'm new to multithreading.
This is the scenario: I'll have a mobile app that will do a lot of queries/requests in my database(Mysql), my goal is to make a server side application that handles multiple queries using C# in a Linux machine(mono to the rescue). My company is doing the database side of the application, there's another company making the mobile app. I'll send the data to the cloud and the cloud server will send it to the client.
I'm reading the threading chapters of CLR via C# and C# 4.0 in a nutshell, but until now I have only a little clue of what I can do, I believe that asynchronous methods would work, since it doesn't use a lot of resources but I'm a little confused about how to handle thread concurrency(priority, state).
So here are my questions:
What is the best way to solve this problem?
Which class from .NET framework suits best for this job?
How should I handle the query queue?
How can I handle thousands of threads/queries fast enough, so my mobile app user can have the query result in a estimated time of 5 minutes?
Some observations:
I know that the data and time to finish a query will be exponentially equal to the size of the user's data in my database, but I need to handle(few and large data) it as fast as I can.
I'm sending the data to a cloud database(Amazon EC2) and from there i'll send it to the client. I'll not handle this, this will be handled by another company, so my job is to get the queries done quickly and make them avaliable to the cloud database.
I'm aware that to send the information to my client I depend on my IT infrastructure, but the point here is: how I can solve this problem quickly in a way that I'll have only to worry about my application infrastructure.
I cannot put the queries on a big string and throw it on the database, because I need to handle each query result separately before sending the result to the user.
The storage engine is MyISAM, so no transactions are allowed.
I would create a REST web service, either on top servicestack or WebAPI, to abstract access to your data via a service. Either of these services would be able to handle simultaneous requests from your mobile client, as they are designed to do so. In addition, I would create a class that can mediate access and provide a unit-of-work to your database (ie repository). The connection provider for MySQL should be able to handle simultaneous requests from your web service, so you should not have to worry about threading and request management. If a single instance is not enough, you can add more web servers running the same code and use a load-balancer to distribute the requests to each of your instances, where the service/data code is the same.
Some resources for mono based web-api/servicestack:
http://www.piotrwalat.net/running-asp-net-web-api-services-under-linux-and-os-x/
What is the best way to run ServiceStack on Linux / Mono?
I am looking for a way user can communicate between an ASP and Winform applications.
I am looking for something like soluto.com, I want to let the user send commands to other computers via Website. So let's say the user signed up for 10 computers, which is registered on the mvc app. User can select all the 10 computer and send a "Do this task" with a click of a button.
I am thinking something like, Winform will create a httplisten server. Everytime winform is open, it will send a "I am online" post to mvc, along with IP:Port. The server will send a request to that ip:port when required.
That approach seems very unsecure though, having an open port, configuring firewall and etc, seems like a overkill.
I was wondering if there way any other way of accomplishing this.
Thank you for the help.
P.S. Before you claim this is a stupid idea, Piriform is doing something like this also. Take a look at Agomo.com
Use SingalR with properly architected web and windows applications (e.g. MVP, MVC, etc.)
SignalR with window client (WPF)
Console App & SignalR
Create a WCF service within the WinForm application, specify endpoint(s) (and secure the endpoint appropriately), and connect to said endpoints from your ASP.NET application the same way you would also connect to a WCF service.
Why don't you just have the Winforms app use a standard HttpClient or WebRequest to periodically poll the service (maybe every 5 seconds or so) and ask if there if there are any tasks that need to be performed?
Unless you need realtime, low-latency, high performance communication then this is the easiest way to solve your problem with minimal to zero client side setup or security configuration.
The way I would do it is implement it like a stack in a data persistence layer. So each client could have rows in a table that are added when a task is queued. When the clients sends an HTTP GET request to the MVC server it will return the an array of tasks for that client and you could have it either delete them from the database right away or wait for the client to send a HTTP command later to indicate which tasks it completed.
You could represent tasks as a simple data object with a few properties, or just a string or int that you can lookup on the client in some way to invoke the appropriate code.
For reasonable security each client just needs to be given a unique key like a GUID or equivalent that it can later send to the server to validate its identity. This is also known as a cookie, secret, or API key.
I'm working on implementing a game server on AppHarbor for a tournament style game. I'm planning on using WCF and C#. I want the server to generate new "levels" every 5 minutes and send it out to all the clients that are online at the time. The clients would then after 3 minutes send back the results of the level (how the player did) and the server will analyze the results and send back the universal results to each client (leaderboards, statistics, etc). And this cycle would repeat.
I'm not sure where I should start. I was looking into making a WCF service application with REST services to get the information, but I don't know who to make the server do calculations and generations independent of the clients.
I would greatly appreciate any help that you all could give me.
Thank you.
You can use SignalR to create independent persistent connections to your clients. At this point SignalR doesn't scale that well as it is only possible to run it on one worker/server out of the box. There is a feature request for scaling but it's not done yet. Depending on how many users you are counting on getting the first months, I would say SignalR is the way to go and then when you need scaling you can improve SignalR to be scaleable as it is open source. :)
I need to create a system comprising of 2 components:
A single server that process and stores data. It also periodically sends out updates to the agents
Multiple agents that are installed at remote endpoints. These collect data in (often, but not always) long-running operations, and this data needs to get to the server
I'm using C# .NET, and ideally I want to use a standards compliant communications method (i.e. one that could theoritically work with Java too, as we may well also use Java agents in the future). Are there any alternatives to web services? What are my options?
The way I see it I have 3 options using web services, and have made the following observations:
Client pull
No open port required at the agent, as it acts like a client
Would need to poll the server for updates
Server push
Open port at the agent, as it acts like a server
Server must poll agents for results
Hybrid
Open port at the agent, as it acts like both a client and a server
No polling; server pushes out updates when required, client sends results when they are available
The 'hybrid' (where agents are both client and server seems the obvious choice - but this application will typically be installed in enterprise and government environments, and I'm concerned they may have an issue with opening a port at the agent. Am I dwelling too much on this?
Are there any other pros and cons I've missed out?
Our friends at http://www.infrastructures.org swear by pull-based mechanisms: http://www.infrastructures.org/papers/bootstrap/bootstrap.html
A major reason why they prefer client-pull over server-push is that clients may be down, and clients must (in general) apply all the operations pushed by servers. If this criteria isn't important in your case, perhaps their conclusion won't be your conclusion, but I do think it is worth reading the "Push vs Pull" section of their paper to determine for yourself.
I would say that in this day and age you can seriously consider only pull technologies. The problem with push is that clients often are hidden behind Network Address Traversal devices (NAT) like wireless routers, broadband modems or company firewalls and they are, more often than not, unreachable from the server.
Making outbound connections ('phone-home'), specially on well known ports like HTTP/HTTPS can basically be assumed as 'possible' even under most constricted networks.
If you use some kind of messaging server (JMS for Java, not sure for C#) then your messaging server is the only server that needs to open a port and you can have two way communication from your agent to the messaging server and from the server to the messaging server. This would allow you to accomplish the hybrid model without needing to open a port on the agent server.
IMHO, I find your best option is the pull option.. that can satisfy your main system requirements as follow:
The first part: Data needs to get to the server, that's obviously can be done through invoking a web method that send that data as a parameter
2nd part:(Server periodically sends out updates to the agents): You can still do that that thru client (regular) pulls by some sort of a web service method that "asks" for the updates since its last pull (some sort of s time stamp to get the updates it missed)
The hybrid method seems a bit weird to me given that I think of an agent as a part of the system that probably might go "offline" quite often, what will the server then do if that failed? it's usually a tough question/decision, specially if you're not sure if this an intended "going offline" or a system/network failure.. etc