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/
Related
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.
I need IPC between a windows service and a GUI application both written in Delphi 2010. I decided to use named pipe for this.
I built and installed successfully Russell Libby's TPipeServer and TPipeClient components (link).
I followed other answers like this.
But my service received only empty messages from the client. After many test I concluded that I was using those components erroneously, so i don't want to post any code here.
So I'm looking for a valid example about how these components work in order to write/read strings in a named pipe (from client to server and viceversa). Any help is really appreciated, even using other free named pipes components or source codes.
Thank you.
Edit: I need a valid way to pass security check in windows server 2008 / windows vista / windows 7
The Cromis-IPC component by Iztok Kacin is a versatile IPC communication Delphi component utilizing windows named pipes. On the given link is a client/server example, and in the source code of the component is a full example.
The Cromis IPC can be used for process communication within the same computer as well as communication between computers on a network. Permissions are easy to handle when doing communication within the same computer. For a detailed description how to handle permissions, see windows doc Named Pipe Security and Access Rights.
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.
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.