I'm writing a download manager in Delphi with some custom features like resumable downloads and downloading through proxies.
I'm studing different component solutions: Indy and NetHTTP, both seem very close.
TNetHTTPClient seem to be an interface of winhttp.dll.
TIdHTTP seem to be an interface of wininet.dll (but i'm not sure).
TIdHTTP seems like a very old component (maybe very stable/tested) and has tons of documentation online.
TNetHTTPClient seems to be a very recent component, and doesn't have good documentation online.
I'm a bit undecided... which one to choose?
The point is: what is the main difference between these two components?
My question is a bit disputable (primarily opinion-based), but I haven't found any practical comparison between these two components.
TNetHTTPClient was introduced in Delphi XE8.
The most important benefit of TNetHTTPClient is that it allows your application to support HTTPS without having to provide your own support for SSL/TLS. TNetHTTPClient relies on the SSL/TLS support provided by the operating system.
This means you don't have to update your application whenever new vulnerabilities are discovered. Your customers will get these updates as part of their operating system updates. Less work for you and better security for your customers (if they believe their operating system vendor to be better at updating SSL/TLS libraries than you are).
It also means the code that encrypts and decrypts the HTTPS traffic is not in your application. So your application is not affected by restrictions on importing or exporting encryption algorithms.
TIdHTTP relies on OpenSSL to support HTTPS. You'll have to ship two DLLs with your application. OpenSSL is an open source project. Some organizations have issues with software that contains open source components. One of our products uses TIdFTP and OpenSSL to support FTPS. Every now and then we have users asking if the product will work without these DLLs (it will, but without FTPS), because their presence makes it more difficult to get the software approved for use at their organization.
I believe that all this was also Embarcadero's motivation for creating TNetHTTPClient (even though they already had TIdHTTP). It moves the onus of making sure HTTPS is secure from the developer to the operating system.
Indy DOES NOT use WinInet/WinHTTP at all. It uses cross-platform BSD/POSIX based socket APIs directly (like WinSock on Windows), implementing Internet protocols (like HTTP) completely from scratch.
TIdHTTP is a manual HTTP implementation.
TNetHTTPClient, on the other hand, wraps system-provided HTTP APIs instead (like WinInet/WinHTTP on Windows).
Related
This is a somewhat general question but I'm hoping someone will have specific info or recommendations.
I have an application suite that includes a service application that acts as a communications interface and data historian for industrial pollution-control hardware. The service contains a singleton COM server to allow the rest of the suite to have access to the hardware and data via the service.
I've read the stuff about how SvCom is required to make COM servers work in Delphi service apps. I have and use SvCom - it does what it claims. But I'm not all that comfortable with it, the product and my coding styles and expectations don't match, and it makes debugging somewhat more of a headache.
But my real problem is with the idea that the lengths SvCom goes to to make a COM server work in a service app is absolutely required. Their documentation, and some of the stuff that comes up in searches on the subject, makes it sound like their toolbox is absolutely required for any COM-server-in-service scenario. But I have a couple of different 3rd-party libraries for implementing OPC servers, Prosys Sentrol and the older Production Robots library (if you're not familiar with OPC, it's a pretty-much ubiquitous data-interchange standard built on COM) and both support the OPC COM server being put in standard TService-based apps without special handling beyond doing in the AfterInstall and BeforeUninstall events what would normally be done in a stand-alone EXE when run with the /regserver or /unregserver command-line switches, and of course using DelayInitialize := True. So at least SOME COM servers can be done as typical TService-based apps without the extraneous steps SvCom goes through.
So my question is: Is the line between "what sorts of COM servers work in a TService-based app" and "what causes the need for the extra stuff SvCom does" clearly known? If so, what is it and/or where is it documented? If not, I'm kind of surprised - seems like implementing COM servers in service apps would be a fairly common need, but I've does several deep searches and, based on the dearth of info I've found on the subject, maybe it's not.
Could someone please explain their differences? Are they same and work the same way? Which one is better than the other components?
They are NOT the same, and they DO NOT work the same way. They take very different approaches to socket API interactions, event handling, error handling, etc.
TClientSocket and TServerSocket are the original VCL-based (Windows-specific) socket components. They were deprecated in Delphi 7 and are no longer installed by default, but are still available for manual install if you want to use them.
TTcpClient and TTcpServer were originally introduced in Delphi 6 as a cross-platform socket solution for Kylix (which is a dead product). They were removed from Delphi in XE6, downgraded to demo status, not even official components anymore.
In my opinion, TTcpClient and TTcpServer are horrible components, you should stay away from them. They use a very minimalistic "least common demoninator" approach to cross-platform programming, catering only to a few basic functions that multiple platforms support, not leveraging any platform-specific features or even higher-level functions. They have a very basic interface that is badly designed. They are very difficult to work with, have bad error handling, and are not very flexible to use.
If you need to write new socket code, TClientSocket and TServerSocket work great if you are only interested in supporting Windows, but if you need to support cross-platform then you should use a third-party socket library, such as Indy (TIdTCPClient/TIdTCPServer), ICS (TWSocket/TWSocketServer), Synapse (TTCPBlockSocket), etc.
I need to take a huge Delphi XE application (backed by proprietary SQL server NexusDB) and begin providing my clients the ability to access the system in new ways:
Thinner Windows client for slow/VPN connections
Mobile/Tablet
Web
DataSnap appropriate for this or is introducing a middle tier the wrong way about providing remote/mobile access? Other solutions/ideas welcome.
(I have XE2 Enterprise but am stuck on XE Enterprise for awhile.)
DataSnap is being aggressively positioned by Embarcadero as a Multi-platform connectivity solution, where servers are written in Delphi, and mobile connectors are available (in XE2 and later) for a variety of mobile device platforms. So the quick answer is yes, it is suitable in general.
Is it suitable for you? You haven't said much that would help me answer that question; You are willing to buy Enterprise or Architect SKUs of Delphi, so I would guess yes.
If it was me, I'd look for a solution that implements a pure simple REST architecture that is available to every system out there, mobile or otherwise, no matter what language or platform, but I haven't got a suggested alternative because it seems to me that SOAP is nearly dead and that there is no universal replacement technology out there that does everything that soap client/server systems do. I'd be tempted to consider "roll your own REST+json" or evaluate Remobject's product offerings too, and select a path that makes sense for you, from a business and technical point of view.
Datasnap is fine, but it's not the only option. It's probably the simplest and most easy to roll out option currently available, and the only one "out of box" ready to go in XE2 if you want apple, android, and a few others, right away.
That depends on your security needs, and the way you're providing data to clients. As I often pointed out, dbExpress-Datasnap has big security flaws (while the DCOM version is not well suited outside a LAN, and does not offer out of the box mobile devices support).
A web application would have less issues because the datasnap-web server connection would be probaby internal, it would be up to the web application to ensure data protection.
I read this question but was somehow not satisfied with the answers.
I also quickly read (as suggested in that question) the last chapter of Marco Cantù 2010 Handbook, from which I quote the following (I think I can quote such a short text):
I [Marco Cantù] do have a lot of
investment in server side web and REST
applications written in Delphi, and in
the recent years I've started playing
with and introducing at conferences a
Delphi Web Application REST
Framework119 (that is, DWARF), which
at this time is still not publicly
available... simply because it is too
sketchy and unfinished to be
published. I've seen other ongoing
efforts to clone Rails in Delphi and
offer other REST server architectures.
I think that if you want to build a
very large REST application
architecture you should roll out your
own technology or use one of these
prototypical architectures.
Considering that I own Delphi XE Professional and DataSnap is not in there and I would like to consider to write large applications too according to the above comments it seems DataSnap is not an option.
Is there even a commercial solution for this? I don't want to consider "my own implementation of REST", I would like to create a webserver that uses some of my datamodules where I use the DAC I choose (Devart in this case).
Final note: my goal is to write the backend for a large web application, on the client I would like to use Ext JS 4.0, but I want to do all the client work in javascript, to take full advantage of EXT JS, so basically I need a webserver just for the data and tracking the state, not for serving webpages.
To create your REST services, try our Open Source mORMot project. Now it is a well known and stabilized project, used world wide in production.
You can use any DAC with the current state of the framework by implementing a custom TSQLRestServerStatic class (similar to the TSQLRestServerStaticInMemory class, but calling your DAC): so you'll benefit for the ORM and the JSON RESTful architecture, together with the high-speed http.sys kernel-mode server.
The SQLite3 engine is NOT mandatory with our framework, even if it was designed to work better with it.
If you will start an application from scratch, I think the mORMot is a good option if Delphi is your only option. If you choose datasnap you'll have to live with the problems of performance and stability.
I wrote an article on my blog talking about performance and stability with DataSnap (and mORMot) in large applications, you can see it on the following link:
DataSnap analysis based on Speed & Stability tests
I think you should have a look at kbmMW, there is a way to implement a basic REST server based on an event driven HTTP server.
Check news.components4developers.com news groups, there you will have a lot of documentation.
FireHttp is a high-performance Web server based on Delphi/Object Pascal language. It supports HTTP 1.1, HTTPS (SSL/TLS), WebSocket, GZip, Deflate, IOCP, EPOLL. It adopts multi-process+multi-threading model, has good stability and concurrency performance, and provides SDK source code. Developers can use SDK to quickly build high-performance cross-platform Web applications.
I'm a C++ programmer, but my question is about the Delphi network socket library Indy.
Essentially as Microsoft crippled raw sockets with WinXP SP2 so that TCP data cannot be sent over them, does this then also apply to Indy? One of my friends recommended it to me rather then using the WinSock API.
If not, then is the only way to use raw TCP sockets using the WinPCap API?
If it doesn't, I know that synapse for Delphi does. The latest version now supports D2009 and it is being actively supported.
As you can see from the other answers there are a lot of Delphi libraries to simplify network programming. However, AFAIK they all provide a friendlier layer over the WinSock API (on Windows, over the standard socket API on other OSs) and thus are not able to do anything that the WinSock API isn't able to do. In particular they may or may not support raw socket access, but if the OS fails to send data over the socket the libraries will only return errors as well.
For more information about the limitations of raw sockets on most recent Windows OS versions see this MSDN page, in particular the section "Limitations on Raw Sockets". It states quite clearly that
To get around these issues, it may be required to write a Windows network protocol driver (device driver) for the specific network protocol.
Neither of the Delphi network programming libraries comes with its own network protocol driver AFAIK. And neither will help you with permission issues on limited user accounts, or the interference of the Windows Firewall.
As you mention WinPcap in your question you know it is capable of doing what you want. There are Delphi wrappers for it, like Magenta Systems Internet Packet Monitoring Components. However, as a C++ programmer you may be better off to use the library directly from C++, as Delphi adds nothing in regard to the socket programming you want to do. In particular you won't need the extra layer to hide platform differences that some of the Delphi libraries provide, as you will be programming directly against the libpcap API.
Indy works quite well. I use it quite a bit with few problems.
If your looking for more basic socket interaction you could use these other components:
TTCPClient
TCPServer
TClientSocket
TServerSocket
All of these components also ship with Delphi.
Don't know about winpcap directly, but I believe there is a delphi wrapper for it. I don't currently know where I've seen it but it shouldn't be hard to find using Google code search.
you should check ICS components
ICS is a free internet component
library for all Delphi, C++Builder,
BDS and RAD Studio versions (win32).
It includes TCP, UDP, raw sockets,
clients, servers, as well as many high
level protocols such as FTP, SMTP,
POP3, NNTP, HTTP and more.
http://www.overbyte.be/
I would rather prefer synapse over than Indy, it's architecture is more simpler thus easier to understand.