I wanna build a Win32 app of Client/Server (or 3-tier) type with follow features:
When the "A" client does a modification (update,insert, etc) into a database, the rest of clients viewing the same record set can get almost "instantly" a fresh view of this data
a client can be notified when a connection to database get lost
could someone help me? Thanks in advance
Pdta: My Database is MySQL 5.1
Note that by doing this, and having lots of clients, you will potentially get a lot of network traffic.
This is exactly the reason that most client-server applications do not do this.
If you really want to do this, then the proper was is to implement the 'observer pattern'; a basic example on that design pattern in Delphi has been described by Joanna Carter in her blog.
Then you need to extend that pattern so it works over a network.
So at least you need some server process that handles the "subject" interface.
You can use anything for that: WebServices, DataSnap servers, RemObjects SDK, etc.
Most people wanting a solution like this, go from the traditional client/server application into a multi-tier application. Then the middle-tier can handle all the notifications for you.
My answer depends on your network architecture but I tend to use IP for this type of thing. Something like Multicast is an ideal way to notify all clients on the Network of an event. Simply multi-casting or broadcasting (UDP) the ID of the updated record may be all that is required. If another client is interested in the record, it can then refresh it from the Database.
The Indy Multicast Client/Server components will provide a simply way to implement this in your app.
If you have a three tier type application, the client communicates with the aplication server. This connection could use callbacks to the clients to notify them about important events. DataSnap supports callbacks (afaik also data change notifications).
If you build your own application server. the client could open a socket connection to the server (in a thread) and listen for event notifications. The Indy Telnet client example in Protocols/IdTelnet.pas is a good starting point to create a very simple notification implementation. It uses the TIdTelnetReadThread class to listen for the server responses to key input and protocol negotiations.
If your application needs to run in Terminal Server environments, where Ports will not be virtualized AFAIK, it is safer to connect from the client to the server (instead of opening client socket ports for peer-to-peer communication).
If MySQL doesnt support somekind of pushing info or attatching clients you would need to use a middle tier running on a server.
That server keeps track of connected clients. But it would probably be a heck of a job.
I know that the "bigger" edititions of Delphi has somekind of support of building this kind of client/server software.
I know it has nothing to do with your application, but Firebird has a nice feature to do exactly this. You can read more about them here (link to a PDF).
Now, if you need to do this with MySQL and Delphi, the easiest way I can think of is doing something "AJAX LIKE" on your Win32 app. That is having a server side app (you could use a WebServer with PHP, Java, .NET or whatever you want) that will serve your requests asking for data updates. On the server side app, just do a query asking for modifications into your MySQL Database.
Hope it helps.
Related
I am currently studying how to make cross-platform mobile apps (with xamarin forms), and I have heard that the "correct" way to connect to a database in a non-locale server (in my case located in Azure) is by using Rest Services (or rest APIs, or however is called), instead of connecting directly to the database with the server explorer option of VS like you would do in windows forms for example(using the SQL connection, dataset, etc. Which I think they are not necessary in the first case, I am not sure).
The only answer that I have received about this is that in mobile apps "They are not permanent connections. It connects, gives you data and disconnects. They are Asynchronous connections.", and that this is done "For optimization of connection resources. The mobile is suspended or the user passes the App to the background.".
But I still don't know if this is the actual reason, and if it is I don't understand how it optimizes the connection resources. So if someone has time to explain this I would appreciate it.
Thank you for your time, I hope I have explained myself correctly, and that you all have a great day.
As Jason said,the Security issues，with proper authorization having mediator is definitely much more secure than giving a user direct access to the database, because you restrict him to the end points which run only the queries you want to.And from the platform independence and maintenance,if the apps are developed in different languages and on different platforms,it may have benefit to create a common REST interface to allow sharing of data model, caching etc.For performance and scalability，that HTTP layer of your REST API provides another valuable caching mechanism. Your servers for your REST API can put caching headers on their responses, and these responses can be cached at the network layer, which scales exceptionally well.
you could read this link Why do people do REST API's instead of DBAL's?,I think the answers are pretty good
So, I've been reading about security in relation to desktop applications and database servers. Previously when I've built applications that are linked to a database, I've taken the easy route and simply stored the connection string hard coded in the source code directly. This has worked since the binaries were not distributed to third parties. However, now I'm working on a project whose binaries are bound for third party use, and in this case the communication with the server becomes a security issue that I need to deal with.
Since it is a priority that there be no direct connection to the remote database from the client machine, I understand that a server/client database service is a good choice. In this case, the client machine sends requests using TCP to a server, which then processes the request using stored procedures and responds accordingly to the client.
My questions in relation to this are:
i. Would this setup be an advisable one, or are other setups of which I am unaware more advisable for the kind of project I am working on?
ii. How does one go about securing such a connection? I can easily set up an SSL connection to the server using a security certificate generated by OpenSSL, however I'm not sure whether this is the correct way of securing the connection for a desktop application, or whether this method is primarily used for HTTPS. And WHEN should one in general secure the connection (are there instances where this wouldn't matter, for instance if all I do is send booleans back and forth?)? Any good resources that discuss these issues? For instance, I have a lot of application installed on my Windows PC that are networked, but I don't see many of them installing a security certificate on my PC. What gives?
Full disclosure: I'm a C++ (hobbyist) programmer using Boost libraries for my network programming needs and OpenSSL for my SSL cryptography. However, I hope this can be answered without paying too much attention to these facts :)
Answers:
i. Having your application talk to a web service that then talks to the database is a better setup. This abstracts the database away from the clients (and therefore direct access from the internet).
ii. This depends on what the threats to your system are. If the data you are vending from the web service mentioned above is data that is not sensitive, and is not user specific (say an app that allows searching of public photo galleries, so your web service simply returns a result set with URLs) then you might be able to get by with simply using SSL. Other apps get around installing their own cert in a myriad of ways. They can either get a cert from a CA like verisign, so your computer already trusts it. Or they can deploy the public cert with the binary of their app, and handle it inside of their app (this is a form of certificate pinning).
ii part 2. If you need the clients to authenticate, for reasons of either wanting to make sure that not just anyone can use your web service, or to support a more advanced authorization model, then you would need to implement some sort of authentication. That would be a much bigger question to address.
Make sure you use CA-signed certificates, and not self-signed. You might also want to consider mutual authentication between your service and the database.
We are building an application that will have clients installed in many sites. Each client work on its own, has its own database and workflows. However, each client has to submit some data to the main application installed at a central position. The application at a central location must receive updates (e.g stock levels) from the distributed units. All applications are done in Java. Which is the best way/technology of sending the updates from the distributed units to the central application? JMS, jdbc, ...?
I'm going to assume that the servers at client sites have network access, and that you are able to configure the central server so that other clients can connect to it. This could either be over the internet or an internal WAN.
In this case, it's simply a case of finding a mechanism to submit some correctly formatted data, which is received and handled by the central server. This gives you a large number of options, I'm going to list just a few:
Create a web service with something like Apache Axis
Use an ESB - something like Mule or JBoss
Use a simple web Servlet on the server, and submit data using HTTP POST. You could use a simple embeddable Java web server like Jetty to do this.
Use a messaging protocol like Kryonet or Google's protocol buffers
Use a more general network application framework such as Netty
All of these will work, so it really depends on working out which is the best fit for your architecture. I suspect the simplest would be something like Kryonet, the most comprehensive would probably be something like a full JBoss ESB/application server stack.
I have a year's experience writing client code but none with server stuff. I want to restrain the question a bit so I'll simplify what I'm trying to achieve.
I want to write server code such that two clients (Browser or iPhone / Android) can connect, when two player have connected they see a timer count down to zero. The clock would be synchronize on the server and the clients would be uniquely identifiable.
The trouble here is with the word connect, what do people use for multiplayer games? Open a TCP socket for two way communications? You can tell I'm not really sure what I'm talking about. I was hoping to use AppEngine but I'm not sure if it's suitable as it's request based.
I have some experience with Java and although Erlang sounds like the best choice this is something I just want to play with and push out fast so Java would be easier. I just need to know the best way to connect players etc.
Thanks,
Gav
I suggest we regard desktop and mobile systems as equal clients. What options are then?
You write a socket server which will accept connections from clients. But then you need to write some socket client as well, even 2x - for a desktop and for a mobile OS. And the user will have to install this client.
You launch a web server (whatever technology you like). It will expose some web services which will be equally accessible to both desktop and clients OSes. But still you need to write a client application (again 2x).
You run a web server and make all functionality accessible via standard HTTP protocol. This way you won't even need a client - almost every desktop or a mobile OS has at least some web browser installed. JavaScript will provide for dynamic updates of your ticker.
There is a good series of articles about Networking for game programmers by someone who does that stuff for a living.
I'm by no means an expert on network communication, but if you don't mind loosing a few packets (or error checking in software) and you want fast, lean communication you could use UDP. I think most time-sensitive data programs and streaming media use this protocol to avoid delays and keep packet size down.
I realized a Client/ Server app a few years ago with java and ServerSocket (http://java.sun.com/j2se/1.4.2/docs/api/java/net/ServerSocket.html). You also have a SSL version.
So you create a ServerSocket and wait for connexion. When a client is connected, you create a thread that will discuss with this client with a protocol that you made.
http://www.developer.com/java/ent/article.php/1356891/A-PatternFramework-for-ClientServer-Programming-in-Java.htm
If found this little framework :
http://www.bablokb.de/jcs/jcs.html
One of the hardest thing is to create your protocol , a good way to learn how to create one would be to understand how work the FTP (or HTTP ...).
You are correct that the J2EE model breaks down with near-realtime or multi-player demands. You migth want to consider the RedDwarf game server project. It does for games what Servlets do for busienss logic and is open source.
http://www.reddwarfserver.org
I suggest we regard desktop and mobile
systems as equal clients. What options
are then?
RedDwarf has a pluggable trabsport layer and can support any sort of client you wish.
Web servers are great for web type apps. if your game acts like a web page-- is not multi-user, is turn based, and evolves very slowly-- then a web server is a fine chocie.
If it doesn't however, you need something a bit beefier in technology.
Oh, and for what its worth, whetevr you do, if you want to write a server from scratch then DON'T use"ServerSocket." That requries a thread per connection and will never scale. Use NIO or use an NIO framewoprk like Netty.
I am building a silverlight app and would like to add p2p capabilities - allowing users to send each other data.
Is it available out of the box?
Should I wait for silverlight 4.0?
Do I need a p2p server?
The key problem is actually opening the client-side socket to accept connections from another machine, and Silverlight doesn't support this, even in out-of-browser mode, and even in Silverlight 4. If you wanted to do something like this, as the other folks have mentioned, you need a common server that both clients can connect to and which will proxy the messages back and forth between clients. And of course, the fact that Silverlight sockets are limited to ports 4502-4532 also means that you're somewhat limited by firewall policies.
What we've done with our applications (using Silverlight 4) is to try to connect with the new support for Net.TCP (which scales much better), and then if that fails, fallback to the HttpDuplexBinding (which runs over HTTP and hence is more likely to make it through a firewall). We then wrote a WCF service which receives messages from one client and submits them to other subscribing clients. It's not P2P, but it allows for a similar result (apart from all the actual benefits of P2P connections).
If you move to WPF, you give up on the portability of Silverlight, of course, but you get full server socket support, along with the ability to code various NAT traversal strategies like STUN and TURN.
I don't think you could make this work in Silverlight with a serverless environment.
You could probably do whatever you're looking to do with a server and a web service, although this technically wouldn't be a peer-to-peer application anymore. You'd have to send your messages to the server, and the server would then send to the appropriate client(s). If you follow this route you might also want to look into WCF RIA Services for Silverlight as it has built-in support for things like authentication.
EDIT -- I don't know if this is an option but it looks like someone has come up with a way to do P2P in Silverlight. However, it requires that you run the app in Windows Live Messenger:
http://www.codeplex.com/SilverlightP2P