This question already has answers here:
Indy 10 Http Server sample
(2 answers)
Closed 9 years ago.
How to write a desktop Delphi 7 Win32 Apps with embedded Http server something like Media Player Classic with Web Interface. I need a standalone HTTP server to be launched from user's browser to a url e.g. http://:/ and request using a GET or POST and then responded from Delphi app.
TCP/IP libraries usually comes with demo projects.
For example http://synapse.ararat.cz/doku.php/public:howto:httpsserver
There are also larger frameworks that provide HTTP server just as one of their services (which still allows you to carve that part of their code and re-use it).
For example (but Henri seems to got fed up with Embarcadero and abandoned his Delphi projects) http://code.google.com/p/delphionrails/w/list
For another example there is http://blog.synopse.info/tag/HTTP
This implementation relies upon Windows http.sys driver, that was developed as a fast HTTP protocol implementation for Microsoft IIS.
During recent DataSnap performance shootouts mORMot-based server, working through http.sys AFAIR, shown great performance with low overhead.
BTW, Indy-based DataSnap was shown to only surviving of low to medium load.
Add an IdHTTPServer to the project.
Related
How can I communicate with CEF via Indy Sockets through Remote debugging protocol?
As described here: https://developers.google.com/chrome-developer-tools/docs/debugger-protocol
I made a Proof of Concept for DWS (pascal to javascript compilation, as used in Smart Mobile Studio) some time ago:
https://code.google.com/p/asmprofiler/source/browse/#svn%2Ftrunk%2F-Other-%2FRemoteDebuggerDWS
You can use my Indy 10 websocket (and socket.io!) components from here:
https://github.com/andremussche/DelphiWebsockets
The API currently requires using the WebSocket protocol which is not supported in Indy. The API documentation page contains this note:
Note that we are currently working on exposing an HTTP-based protocol
that does not require client WebSocket implementation.
There are WebSocket client libraries available for Delphi both free and commercial (some use Indy as their internal TCP library).
You will also need a JSON library, available in newer Delphi versions and also as free open source (for example SuperObject and lkJSON).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am looking for some starting points integrating a Win32 Delphi application's data with a remote database for a web application.
Problem(s) this project intends to solve:
1) The desktop does not perform well over vpns. Users in remote office could use the web app instead.
2) Some companies prefer a web app to the desktop app
3) Mobile devices could hit the web app as a front end.
Issues I've identified:
Web application will run on a Unix based system, probably Linux while the desktop application uses NexusDB while the web application will likely be Postgres. Dissimilar platforms and databases.
Using Delphi it appears the Microsoft Sync Framework is not available for this project.
My first thought was to give the web app your standard REST API and have the desktop app hit the API as though it's a client every n-minutes from the local database server. Tons of issues I see with this already!
Richard, I have been down this path before and all I can say is DON'T DO IT! I use to work for a company that had a large Delphi Desktop Application (over 250 forms) running on DBISAM (very similar to what you have). Clients wanted a "Web" interface so people could remotely work and then have the web app and desktop app synch changes. Well, a few years later and the application was horrible - data issues and user workflow was terrible because managing the same data in two different places is a nightmare.
I would recommend moving your database to something like MySQL (Delphi and Web Client both hit) and use one database between the two interfaces. The reason the Delphi client is not working well over the VPN is because desktop databases like NexusDB and DBISAM copy way to much data over the pipe when it runs queries (pulls back all the data and then filters/orders, etc)- it not truly client / server like SQL Server or MySQL where all the heavy lifting is being done on the server and only the results come back. Of course, moving the Delphi app to DB like MySQL could eleviate speed issues all together - but you don't solve #2 and #3 with that.
Another option is to move the entire application to the web and only have 1 application to support. Of course, a good UI developer in a tool like Delphi can always make a superior user interface to a web app - especially in data-entry heavy applications - so that may not be an option for you.
I would be very weary of "synching data".
My 2 cents worth.
Mike
If you use a RESTful based ORM, you could have both for instance AJAX and Client Delphi applications calling the same Delphi server, using JSON as transmission format, HTTP/1.1 as remote connection layer, Delphi and Javascript objects to access the data.
For instance, if you type http://localhost:8080/root/SampleRecord in your browser, you'll receive something like:
[{"ID":1},{"ID":2},{"ID":3},{"ID":4}]
And if you ask for http://localhost:8080/root/SampleRecord/1 you'll get:
{"ID":1,"Time":"2010-02-08T11:07:09","Name":"AB","Question":"To be or not to be"}
This can be consumed by any AJAX application, if you know a bit about JavaScript.
And the same HTTP/1.1 RESTful requests (GET/POST/PUT/DELETE/LOCK/UNLOCK...) are already available in any Client HTTP/1.1 application. The framework implements the server using the very fast kernel-mode http.sys (faster than any other HTTP server on Windows), and fast HTTP API for the client. You can even use HTTPS to handle a secure connection.
IMHO, using such an ORM is better than using only a database connection, because:
It will follow more strictly the n-Tier principle: the business rules are written ONCE in the Delphi server, and you consume only services and RESTful operations with business objects;
It will use HTTP/1.1 for connection which is faster, more standard across the Internet than any direct database connection, and can be strongly secured via HTTPS;
JSON and RESTful over HTTP are de-facto standard for AJAX applications (even Microsoft uses it for WCF);
The data will be transmitted using JSON, which is a very nice format for multiple front-end;
The Stateless approach makes it very strong, even in unconnected mode;
Using a local small replication of the database (we encourage SQLite for this) allow you to have client access in unconnected mode (for Delphi client, or for HTML 5 clients).
I recommend you have one database, and two front ends (web UI that calls SOAP methods for its back end work, and a SOAP method call based rich client in Delphi, and a SOAP server tier that implements SOAP accessible methods which contains your business logic).
From what you're describing, you think replication will merely speed you up, but what it will do instead, is slow you down and cause you to have replication, coherence, and relational integrity problems that must be sorted out by hand (by you).
Take a look at this
CopyCat is a database replication
engine, written as a component set for
Embarcadero Delphi. CopyCat has been
in production use since 2004, and is
very stable. It is relied upon daily
by a number of small to large
businesses for applications ranging
from inter-site synchronization,
itinerant work, database backup and
more. We are confident that it can
fulfill your needs as well. Read on...
I've not been doing bare metal TCP/IP for about 18 months, so I wonder what the current state of the art is.
I'm looking for both positive and negative aspects, with development of both server and client software.
I will be doing a project that needs a rock-solid TCP/IP layer, so for me that is an important aspect :)
For this to become a community wiki, I'm looking for broader answers than just 'rock solid'. So for instance information about the feature-width is also appreciated.
I'll be updating the question with relevant aspects found in the answers in order to get a wiki entry that has a balanced overview of those libraries.
For example, see my answer below with my past experience with Indy
I'm ambivalent on the exception handling and anti-freeze in Indy, though I got used to it, it still felt somewhat unnatural.
Right now I develop in both Delphi 2007 (non Unicode) and XE (Unicode), so the libraries I'm considering should support at least those two Delphi versions.
Edit: Summary of my past experience with Indy, and the comments (thanks Eugene, Marjan)
(please update with the current Indy state of the art):
Pro:
ships with Delphi
mature
development community
open source so lots of eyes scrutinizing those sources
a truckload of valuable comment documentation in the source code
OpenSSL support
supports a broad set of Delphi versions (including 2007 and XE)
wide choice of protocols
Con:
the version shipping with Delphi was not always the most stable one; download from the sources was usually required to get a stable build
(in the mean time) lots of duplication of code that now is in Delphi (but Indy requires for compatibility with older Delphi versions)
not all TCP/IP components were up-to-date (for instance, back then the POP3 client component did not support some basic POP3 commands)
version interoperability was a pain: upgrading from one Indy version to another could be very time consuming
I'm ambivalent on the exception handling and anti-freeze in Indy, though I got used to it, it still felt somewhat unnatural.
breaking changes are made between build updates; ifdefs required to accommodate those
Unclear release status if any at all, no RCs for a long while, getting trunk can make your local copy unstable
ICS - The Internet Component Suite
ICS - see www.overbyte.be. Open source by François Piette. To me this has always been the number 1 alternative to Indy. It's most interesting selling point: it makes using asynchronous stuff easy, and being async seems to be closer to "bare metal" sockets programming.
I've used it to build a fairly complex VNC proxy where the proxy itself (server) is built with ICS and the clients are a mixture of Indy and ICS. In periods of high demand the proxy handles about 100 simultaneous connections and about 10 simultaneous VNC screen sessions. It eats up an average of 5 mbit/s, handles connections over two distinct Internet connections. I don't think the 100 + 10 is the limit, because the server handles that without any problems and CPU usage is too low to mention.
Pros:
Works asynchronously
Somewhat easier on beginners because it doesn't need threads
Supports a good number of protocols
Cons:
Relies on Windows messaging. I'm simply not comfortable with that.
The async behavior makes implementing most protocols slightly difficult (because most protocols are in the form of send command / receive response). This shouldn't matter for most people since ICS offers ready-made implementation for the most-used protocols.
All that being said, I haven't used ICS in a very long time, I'm not up-to-date with all the bells and whistles. This is CW, so please edit and expand!
I have used Indy since 2003 for my own TCP communications framework. It is rock-solid, I have a version used with Delphi 2007 and another with Delphi 2010, if you handle the threadng correctly there is no need to use the anti-freeze stuff, and I have consistent exception handling on the client and the server by implementing my own wrapper around this.
You can dowload it here (http://www.csinnovations.com/framework_delphi.htm) - look for the Tcp units, mainly AppTcpServerUnt and AppTcpClientUnt.
I would strongly recommend Clever Internet Suite, it's by far the best designed and written set of communication components. It's not free and so not that well known, but it's well worth investigating.
Pro:
well designed and written
contains many components and implements various protocols.
supports a broad set of Delphi versions (including 2007 and XE)
SSL support
mature product as the release history indicates
Con:
not open source
You could consider using a higher protocol level like HTTP, because:
It's more firewall and VPN friendly;
It's well documented and known as a good protocol;
It already has secured HTTPS version;
It has a very low overhead over row TCP/IP;
It's ready to use in an AJAX environment (if you need it in the future);
Microsoft already did the low-level tuning for you in modern version of Windows.
In this case, you could take a look at two Open Source classes working from Delphi 6 up to XE:
THttpApiServer which implements a HTTP server using fast http.sys kernel-mode server:
The HTTP Server API enables applications to communicate over HTTP without
using Microsoft Internet Information Server (IIS). Applications can register
to receive HTTP requests for particular URLs, receive HTTP requests, and send
HTTP responses. The HTTP Server API includes SSL support so that applications
can exchange data over secure HTTP connections without IIS. It is also
designed to work with I/O completion ports.
The HTTP Server API is supported on Windows Server 2003 operating systems
and on Windows XP with Service Pack 2 (SP2). Be aware that Microsoft IIS 5
running on Windows XP with SP2 is not able to share port 80 with other HTTP
applications running simultaneously.
TWinHTTP which handles client-side HTTP/1.1 request using the WinHTTP API:
Microsoft Windows HTTP Services (WinHTTP) is targeted at middle-tier and
back-end server applications that require access to an HTTP client stack;
Is much faster than older WinINet API.
Resulting speed is very good (especially the server), and you will rely on Microsoft implementation. The first is the core of IIS, and the second is used in the latest versions of Internet Explorer.
The answer really depends on many factors and your requirements, such as
what layers are needed (TCP, SSL/TLS, application-level protocols)
whether you need a client or a server as well (server is much more complicated task)
whether you count paid options.
In general, not much (positive) happened in 18 months or even in 3 years as most developers look at .NET as primary development platform.
Clever Internet Suite mentioned in other answer and DevArt's SecureBridge gained some new functionality.
Our SecureBlackbox offers support for the most advanced features (besides native SSL/TLS): IPv6, HTTPS Proxy with basic, digest and NTLM authentication (starting with SecureBlackbox 9), International Domain Names (starting with SecureBlackbox 9), DNSSEC, bandwidth control and more.
Application-level protocols supported by SecureBlackbox are HTTP (client and server), WebDAV (client and server), FTP (client and server), SSH and SFTP (client and server), SMTP and POP3 clients, DNS client, AS2 and AS3. All of the protocols (besides SSH and SFTP, of course) have complete support for SSL/TLS.
The list of supported protocols can be found on Packages page. Supported protocol features are listed on Technical Specification page for each package.
Worked with NetMaster components way (way!) back in the old Delphi versions (2! 3! 4!)
Did some work with Indy, but had the unnatural feeling also (actually I'd describe it more as bulky)
Stumbled upon Synapse when I was searching for just a light wrapper around the Windows network API,
And then rediscovered plain old TTcpClient/TTcpServer. They are Delphi's own wrapper around winsock! I use them blocking, with a dedicated TThread inheritant for each TTcpClient, and let TTcpServer do the threads and do all the work in DoAccept, see here for an example.
This, fow now, gave me the rock-solid feel we're looking for. If you want to support heavy load, I would try and build a thread manager that handles several sockets/connections per thread, or have two sets of threads: a few that listen a larger number of 'dormant' connections, and the others that handle lesser 'active' connections, switching connections between the threads depending on wether a request or response is being handled. (e.g. HTTP's Connection: keep-alive)
We have a C/S application all written in Delphi (Client and Server-or middleware if you want)
For the client part we use Indy.
For the server we use DXSock.
Since DXSock is dead for a while we are investigating alternatives for the sever part.
I want to hear some comments about the best Server Socket alternative component for Delphi.
The current system usually have tens of permanent connections working each one on its own thread but could be hundreads in the future (this should be improved to a thread pool if possible)
If you want to have the best possible performance, you'd have to use sockets in non blocking mode, or using completion ports. IPWorks is implemented like that, as well as iocp. As far as I can tell, Indy or Synapse don't implement them (at least officially).
We used completion ports and a thread pool in our open source SynCrtSock unit, used in our Synopse SQLite3 framework.
Here are some benchmarks of this solution, working from Delphi 6 up to Delphi XE. I don't tell this is the "best component", but it's a working and speedy one (every request is about 4 KB of JSON data):
Http client keep alive (i.e. one HTTP/1.1 client connection kept alive during requests):
first in 7.87ms, done in 153.37ms i.e. 6520/s, average 153us
Http client multi connect (i.e. one new HTTP/1.0 client connection created for each request - this one uses completion ports and a thread pool):
first in 151us, done in 305.98ms i.e. 3268/s, average 305us
For speed comparison, here are other communication protocols available in our framework:
Named pipe access:
first in 78.67ms, done in 187.15ms i.e. 5343/s, average 187us
Local window messages:
first in 148us, done in 112.90ms i.e. 8857/s, average 112us
Direct in process access:
first in 44us, done in 41.69ms i.e. 23981/s, average 41us
We use HTTP/1.1 protocol over TCP/IP, because there is very little overhead over plain TCP/IP, and this is a well handled protocol for firewalls and such, and allows our framework to be used by an AJAX application, whereas its main purpose is to serve Delphi clients.
IMHO there is no "best Server Socket alternative component for Delphi", it depends what is the purpose of your server application. The main bottleneck will be in the Windows kernel itself. Perhaps direct access to the HTTP Kernel-Mode Driver (Http.sys) of Windows could help.
Consider using a dedicated optimized Server instead of a Delphi server, like lighttpd or Cherokee using FastCGI to handle the requests via a Free Pascal (or CrossKylix) application, under Linux. I guess this will be the best performance possible.
I use Indy components for commercial server-side work and the component set is pretty solid (9 or 10). My servers have millions of connections per day with no issues.
I used DXSock many moons ago. He was always optimizing, but never seemed to finish it. He does seem to have another version out.
If you want commercial support, then I'd recommend IPWorks from nSoftware.
Actually DXSock is not dead, v6.1 was just released. The web hosting company we used to use in Tennessee lost the domain - so only customers who have kept their subscription renewed annually have received DXSock 5.0, 6.0 and 6.1.
Indy CANNOT support more than 2,000 concurrent connections on 32bit Windows - as Chad and crew use TThread, which implements the defacto 1MB per thread/socket connection - 2000x1MB = >2.5GB of RAM which 32bit OSes do not support. DXSock implements a 0b per connection model (unless you define otherwise) and can handle over 50,000 concurrent on Windows, Linux, Mac, Pi, etc.
Ozz Nixon - ozznixon#bpdx.com if you want more details on 6.1
Author of DXSock
Co-Author of Winshoes which became INDY.
Has anyone had any experience of talking between an iSeries (using IBM's Websphere MQ) and PC code - hopefully using Delphi 2009.
Modification:
I have a large PC based program (that talks to an iSeries) that I need to rewrite. One option would be to do most of the tricky and processor intensive processing on the iSeries and then have that program signal the PC based program (written in Delphi at the moment) to do the part of the processing that are best done on the PC. So I need to signal the final part somehow from the iSeries, without it polling the iSeries all the time.
First option: add a Java app to the Delphi side which uses a JMS client to listen to an event topic on the MQ server, which receives a complete message from the worker process and forwards this message to the Delphi app (over TCP/IP or other simple IPC methods).
Second option: implement a simple web service server in the Delphi app which has only one method notify() and call this service from the WebSphere side. An example for a stand-alone SOAP server for Delphi 7 (but can be modified to work with D2009 too) using Indy can be found here.
I haven't tried to get it to work, but this looks interesting - http://jamiei.com/blog/2009/02/Delphi-mqtt-client/