Socket programming to control the number of clients - c#

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.

Related

Realtime updates between C# desktop app, mobile app and SQL server

Can anyone explain the best practice communication flow for a multi-app solution I am currently working on. I will have a MS SQL server database running. This database will be accessed and updated by one or more windows desktop applications and mobile devices(android, iOS and Windows). Whenever any changes are made to the database, the clients should be updated in real time to reflect. The desktop applications are most important and need to be updated with as little delay as possible. The mobile apps on the other hand can tolerate a delay of a minute or so.
My idea is connect the desktop application to the server using signalR, the database will then notify any connected clients of the update via SQLDependency. For the mobile side, I was planning for the server to send notifications to the mobile devices, where upon receipt of the notification, the mobile device would requery the SQL Server (via web service) to update itself.
I guess my question is, is this the best (standard) way to go about this or is there a better/quicker/more robust way to achieve this.
Any advice would be appreciated.
I would suggest you create an API in C# and host in on IIS. Your desktop app (be it web or native) will then use RESTful calls to the APIs.
The API's, hosted on IIS would communicate to SQL Server. For database operations, you would have CRUD (Create, Read, Update, Delete). You would expose a GUID (generated using NEWID() in sql server) to each CRUD method and supply serialized data. E.g. perhaps XML or JSON POSTed to the API.
In my view (and practice), this is the Best option. It is truly global, and the API's can "talk" to any client app capable of making HTTP requests.
So the system becomes:
SQL Server > API/IIS > Client (Android, iOS, JS, Java, Windows, Unix, Mac, etc)
Benefits here also are:
SSL out of the box
RESTful transactions - can use oAuth or write your own (proprietary is harder to hack!)
Highly scalable - IIS support 100's of transactions per second
Do not need to open port 1433 (SQL port) to web (which will open you to hacking). API uses port 443 (HTTPS)
If you write your API using C#, you have many serialze/deserialize functions out of the box.
Hope this answers your question.

Connect via GPRS to SQL Instance without public IP

We have the following set up:
Windows Mobile Device with GPRS connection
Windows Server PC with SQL Server 2012
VPN Network where both devices contained (the cell carrier routes certain IPs inside VPN)
Status:
With the above set up I can ping directly from the mobile device to Windows server internal IP via GPRS.
Question:
Can I create connection to SQL server from my Mobile using the server's internal IP?
My con string is:
"Data Source =xxxxxxxx,1433;Initial Catalog=xxxxx;Integrated Security=SSPI;User id=xxxxx;Password=xxxxx;Connect Timeout=15"
EDIT:
More Questions:
How can I implement it if yes
What are the pros and cons in accordance to David's comment
If you have a VPN and can ping the internal server then you can connect directly to SQL Server using the normal data access libraries available in the .Net Framework. Having said that, I would strongly advise against it. It's much preferable to have a middle tier service that interfaces between the mobile device and the database. Here are some reasons (off the top of my head) why this is better:
Mobile connections are inherently unstable and SQL connections are not great at handling that.
Having a service means you don't even need a VPN as it can be public facing (with relevant security of course).
If in future you decide to move form SQL Server to DocumentDB/Azure/carrier pigeon, then you need to update every single mobile device to cope with the change. If you have an intermediate server, you can just update that.
If database schema changes, you may break all of your client applications in one go.
Your middle tier can do other useful things like caching, logging etc.

Real time data update framework

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.

Instant notifications like Facebook

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.

Disconnected Architecture With .NET

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.

Categories