I have a client/server application, where the client side is written in Flex/Air, and the server side in Scala.
The client side uses a local SQLite database that I would like to generate on the server side (it is small, so it can be retrieved via http when needed).
The frequency of updates is low: more or less one per day. The complication is that the database uses the Air extensions to SQLite, so it has to be generated by an Air application.
I have thought of two possible approaches:
Write a small server program in Air, and trigger it from my Scala application via
sockets. Data would be passed to the Air application in the http body.
Execute the Air server program from the Scala application whenever I need the updates to be made. Data would be passed via a file (I don't think an Air application can read stdin).
I am more inclined for the second option, since it would require less admin work (no need to check if the Air side of the server is up). However, I am not sure about the ability of Air to run as a "console" application (I don't like the cumbersome idea of creating a temporary file to pass data).
Has anybody had a similar problem before?
Related
I am using a c program to write/delete 1-2MB of data periodically (10min) to sqlite3 database. The program also act as a read only database for my node.js web server to output Restful APIs. (I can not use node.js modules because node.js web server is on different machine)
In documentation its mentioned that in client/server architechture RDBMS might be good but that point is not put strongly
I am using a c program to act as a server to answer web servers request as well as other processes on different machine. The system require small data (~2-5Mb) frequently (every 5min).
If it is not good to use sqlite as client server database How can I convince my manager?
If its okay then why do they not have a standard server plugin?
When the SQLite documentation speaks about a client/server architecture, it says:
If you have many client programs accessing a common database over a network
This applies to whatever program(s) that access the database directly. (In the case of SQLite, this would imply that you have a networked file server, and that multiple clients access the database file directly over the network.)
If you have a single process that accesses the database file, then you do not have a client/server architecture as far as the database is concerned.
If there are other clients that access your server program, this has no effect on your database.
I am trying to develop a cross application model/view scheme using Qt. What I mean attempting is to have:
Data: SQL Server
Model: Server Application
View/Controller: Client Application
This is for security reasons so that the Client App does not communicate directly with the server. Instead the communication between the model and the data server is handled via proxy Server App which runs on the same server as the database. Communication between the latter two is easy since Qt has the classes to handle it already and they are relatively easy to sub-class.
The problem for me is how to establish the connection between the model (based in the remote Server App) and the view (in local Client App).
I will present my ideas I gathered from researching the topic if it is the right direction but I would really appreciate some guidance. So first I will establish the network socket-based connection between the two apps. But what then? Is it possible to simply "link" the model in the Server App in the Client App as if they were part of the same app? Or should there be the model in the Client App as well and the connection would be used for synchronization between the two models? Or something different?
Thanks for help!
You definitly will have to implement some kind of protocoll. There is no benefit in security if you just link the complete model from server to client. More you will have a local copy in your applications cache for repesenting the data. You need to define what to sync and when to check for new data or send data back to the server. After that start implementing the most basic protocoll options and start sending some data across. On top of that start implementing any more features you need.
I need to find the most efficient way to communicate from an asp.net web server and a windows C++ application. The windows application does not have any permission to access the database of the asp.net web server.
When the user presses a button, that action with some bytes should be received by the C++ application.
In return, after processing the data on the C++ application, it will send back the result to the web server.
The only way I can think of at the moment is as following:
The asp.net web server will have two web service methods:
the C++ application will call that web service for a method for an interval. if there is a change, then the C++ application will process.
after the C++ application finished its process, it will call a method on that web service to inform about the result.
Any other ways to solve this kind of communication?
Thanks in advance.
If the C++ Application is also on Windows, named pipes would be a good solution. They can be configured to be durable so they can queue messages if either side is not ready to receive the message and they are quite easy to use. They basically look like files that you can read or write from and the data appears on the other side of the "pipe".
Take a look at the documentation (C++) here: http://msdn.microsoft.com/en-us/library/aa365781(v=VS.85).aspx
On the ASP.NET side you would use .NET API's. Here's a nice example to get you started: http://msdn.microsoft.com/en-us/library/bb546085.aspx (This example includes both client and server code.)
Named pipes would be a great solution if the C++ application is located in the same physical server as the ASP.NET application. In that case the OS would be just moving memory between processes for you so it could be very quick.
Additionally, I would configure the C++ Application as a Windows Service so it's always available and can be restarted when the server it's running on is restarted. If keeping it running is very important you could integrate Performance Counters and then have your ops team monitor the counters to make sure it is operating within expected thresholds.
The C++ application can also make a simple GET or POST request with enough information that the webserver can handle in case you don't want to expose a webservice.
You could use network sockets. It's been a long time since I have done anything with them so I can't be much help. Research Winsock (aka Windows Sockets API).
You could use WCF services and connect to them using your C++ client. You will have to research consuming WCF services from C++ client.
As #parapura suggested you could use simple HTTPRequest get & post methods. You could create your own http handler for these request to customize the response.
As you suggested you could use simple web services.
If I'm going to develop a web application in ASP.NET using db4o what kind of database would it be: local or remote type, and why?
I think you mean "embedded" vs "client server" (those are the two basic modes that db4o can operate in.
You will most likely want "client server" so that you can spin up multiple client sessions (perhaps one per request?).
The decision as to where to put the database depends on your scenario. Ideally, you would architect your solution so that you could do it either way via configuration. The way you can service up db40 in process in the case of a single server deployment.
However, if you need more horsepower, you could serve the db40 off of another machine to distribute the work. Note that in this case you will have more network overhead / latency.
The C/S mode of db4o implies network communications and is slower. If you need multiple client sessions you don't necessarily need to go with C/S because there's an embedded server mode that allows to have multiple transactions in parallel without the overhead of networks communication:
http://developer.db4o.com/documentation/reference/db4o-8.0/java/reference/Content/client-server/embedded.htm
So if your use case allows it you could open an embedded server on the web server side and allow your server side asp.net app to talk to db4o using multiple transactions (eg one per web session) to persist objects. Note that under this scenario you can't persist objects from the client side (the web client talks to the server side of your app which takes care of persistence).
Important: in web scenarios is not uncommon that you close the db4o object container when a session is over. If you do this the object is no longer tracked by db4o and it will be treated as a new one on the next session. You'll have to find a way to reattach objects to its db4o identity on the server side for a different session (you can do that by querying for the object again on the server side).
Best!
German
Imagine you have a web site that you want to send a lot of data. Say 40 files totaling the equivalence of 2 hours of upload bandwidth. You expect to have 3 connection losses along the way (think: mobile data connection, WLAN vs. microwave). You can't be bothered to retry again and again. This should be automated. Interruptions should not cause more data loss than neccessary. Retrying a complete file is a waste of time and bandwidth.
So here is the question: Is there a software package or framework that
synchronizes a local directory (contents) to the server via HTTP,
is multi-platform (Win XP/Vista/7, MacOS X, Linux),
can be delivered as one self-contained executable,
recovers partially uploades files after interrupted network connections or client restarts,
can be generated on a server to include authentication tokens and upload target,
can be made super simple to use
or what would be a good way to build one?
Options I have found until now:
Neat packaging of rsync. This requires an rsync (server) instance on the server side that is aware of a privilege system.
A custom Flash program. As I understand, Flash 10 is able to read a local file as a bytearray (indicated here) and is obviously able to speak HTTP to the originating server. Seen in question 1344131 ("Upload image thumbnail to server, without uploading whole image").
A custom native application for each platform.
Thanks for any hints!
Related work:
HTML5 will allow multiple files to be uploaded or at least selected for upload "at once". See here for example. This is agnostic to the local files and does not feature recovery of a failed upload.
Efficient way to implement a client multiple file upload service basically asks for SWFUpload or YUIUpload (Flash-based multi-file uploaders, otherwise "stupid")
A comment in question 997253 suggests JUpload - I think using a Java applet will at least require the user to grant additional rights so it can access local files
GearsUploader seems great but requires Google Gears - that is going away soon