I have build a few apps that receive and send data over a Datasnap server.
I have multiple Datasnap servers running on my customers servers.
The Datasnap server runs as a Windows Service on their machines.
How can I remotely update those servers or what is the best way to do this?
Is it maybe better to make the Datasnap Server run on IIS instead of as a Windows Service?
Can I let the server update itself? Maybe if I make a function that sends the new version of it that it can replace itself?
I can see no way of updating the exes on your customers' machines without a) getting them to do it; b) logging in remotely using something like VNC (though I'd be happy to know of a better way).
This is an approach I would consider:
I would look to have a separate application which is called by the service on a regular basis (daily/weekly) that looks for a new versions of software on your server (or somewhere), downloads it stops the service, replaces the service's exe and restarts the service.
In the new service exe I would have something that calls this application periodically, so you only have to do this once.
This assumes the machines that run your software have internet access.
Don't forget to include a mechanism to update the updater application.
Related
I am working on a project that will essentially run each part of a program on a complete separate computer. Reason for this because these are data servers, gaining data from a target program launched on the main users desktop. (very CPU intensive)
The application just needs to be able to send data and things like this across a network.
One is a Console app and the other is a C# made operating system(Technically WPF, but replaces windows and just leaves a kernel).
So how would I go about doing this?
Since both applications are in C#, the easiest way will be to use Windows Communication Foundation (WCF) - https://msdn.microsoft.com/en-us/library/ms734712(v=vs.90).aspx
It allows you call remote methods as though they are just plain local methods.
I'm planning on writing a control panel for Minecraft in Rails but I don't have much experience with Java at all, Minecraft seems to have some standard remote connection and query tools, but most conventional panels don't seem to use them. For example with McMyAdmin, I have disabled remote connectiona and the query, but it still seems to be able to communicate with the server after restarting it after I've edited the server configs to disable the settings.
What I'm asking is if anyone knows how McMyAdmin communicates with the Minecraft server, it comes with a plugin, but I've deleted that as well and it still seems to be able to communicate with the server, I know McMyAdmin is written in .NET and I believe it uses Mono as it's server, as it's cross platform.
If anybody could shed some light on this I'd be ever so greatful, just trying to get my head around the communication.
McMyAdmin uses the plugin to open a socket that it can interact with(Not sure which features are provided using this plugin). The rest of the features are just from the Process instance that it creates. It also just edits the config files for a few things as well or runs commands using the input stream of the process.
I'm a hobby programmer trying to build a client/server application suite, using Delphi XE.
I write stand-alone applications occasionally, for my personal use. The problem is I don't know ANYTHING when it comes to networking / multi-tier. I am willing to learn though.
I looked for ways to do this and DataSnap and IntraWeb jump out as the most likely candidates for the job. But, before I start using one or the other, I would like to know a few info I wasn't able to find on the web:
If I build an IW stand-alone app and deploy it on my site (as server) will I be able to connect to it/retrieve data with a client application? I need to do that within my Delphi written app, without using a browser and without using HTML (I know very little HTML and I'm not eager to learn). I know IntraWeb isn't meant for this, but will it work?
If I go with DataSnap and build a server app, will I be able to deploy it to my website? Or do I have to make a computer on the network the server?
In case anyone wants to know, I want to connect 5 computers(from different cities), to exchange information between them, if at all possible using ADO, as I'm very familiar with it.
Intraweb is a server based tool for building web sites, accessed via a browser. It is not "proper" multi-tier, and it sounds like it isn't what you need.
DataSnap is designed to do what you want I think. First, the ADO part would be on the server, and you would define an interface that the server offers to do tasks. Then your clients would call that interface over the internet to get data or do those tasks etc.
As for whether they will work on your web server, that depends on what your server is, and the access that is provided to it. A web server is just a PC, but typical hosting is fairly restricted to running "scripted" languages on that server, which reside in the hosting directory. A Delphi server would be a running executable (usually a Windows Service), listening on a port, and needs much more access to the computer than typical. You would need at least a virtual Windows server with administrator access to the desktop to allow it to work. In the first instance though, you could happily run the server on a DSL line or similar and make it work just fine. You can worry about hosting it on the net when you have customers paying for it.
I am a seasoned Delphi developer and would like to create something like seamless terminal services where an application is executed on a server but appears on the the desktop of the client.
To someone working on the server I don't want them to see the remote application running (except if they looked in at the list of running processes).
I'm lost as to how to go about this, where to start, how to get an application to render to a surface other than the servers desktop.
Starting from 2008 Terminal Services (which has been rebranded to Remote Desktop Services) offers RemoteApps which do exactly what you describe. Citrix (XenApp) can do this on all windows (server) versions. So you might want to look at those products before deciding to recreate them yourself.
If you do decide to go on, this link might be interesting, it's a sample project called "Extending Microsoft's Terminal Services Client To Provide Seamless Windows"
From what you are describing, I'd say you should be looking at writing a windows service (not terminal services) and using a inter-process-communications (IPC) system to get status information to a "client" application that can be run by the appropriate user, either on the same machine or another over the network.
Myself, I do exactly this using the RemObjects SDK which makes my client application look like it is just making function calls, but actually they go to the server which implements them. The server can then get on with its job in one (or more) thread, and all the user interface is done in the client which finds out what to display using the IPC channel.
Is it possible to emulate incoming messages using Indy (if it's of any importance: I'm using Indy 10 and Delphi 2009)? I want to be able to create these messages locally and I want Indy to believe that they come from specific clients in the network. All the internal Indy handling (choice of the thread in which the message is received and stuff like that) should be exactly the same as if the message would have arrived over the network.
Any ideas on that? Thanks in advance for any tips.
What you want to do has nothing to do with Indy, as you would need to do this on a much lower level. The easiest way to make Indy believe that messages come from a specific client is to inject properly prepared packets into the network stack. Read up on TCP Packet Injection on Google or Wikipedia. EtterCap is one such tool that allows to inject packets into established connections. However, this is definitely going into gray areas, as some of the tools are illegal in some countries.
Anyway, all of this is IMHO much too complicated. I don't know what exactly you want to do, but a specially prepared client or server is a much better tool to emulate certain behaviour while developing server or client applications. You can run them locally, or if you need to have different IP addresses or subnets you can do a lot with virtual machines.
Indy doesn't have any built-in mechanisms for this but thinking off the top of my head I would recommend building a small test application (or a suite) that runs locally on your development machine and connects to your Indy server application to replay messages.
It should be irrelevant to your Indy server applications if a TCP connection is made either locally or from a remote host as the mechanisms by which a server thread is created and a command processed is identical to both scenarios.
My last gig involved using Indy and all our testing was done with a similar Resender type application that would load local message files and send these to the Indy server app.
HTH and good luck!
One thing you can do would be to create virtual machines to run your test clients, that way they will not be seen as "local machine", and its fairly simple to create a complex network with VMS -- provided you have enough memory and disk space. The other advantage of testing with VM's is you can eliminate the development environment completely when its time to focus on deployment. Amazing how much time that saves alone.
VirtualPC is a free download from Microsoft and works fairly well. VMWare has another option, but costs a little more to get started. For development purposes, I prefer the desktop versions but the server versions also work well. You will still need to have a license to install the virtual OS. MSDN membership is probably the cheapest way to go, and allows you to build test environments for other flavors of the OS.
Indy has abstract stack mechanism for crossplatform support (IDStack.pas) I think u can hack the stack for windows (IdStackWindows.pas). It is a class. U can even consider to derivate it and override some functions to do the hack.