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.
Related
For cross-platform development, I am not sure what is required to make Delphi code cross-platform which uses PostMessage and SendMessage calls for intra- and interprocess commuication, as there is little information about a new runtime library for Delphi.
On the web there are quite many Delphi code examples which uses the Windows message queue for programming tasks (for example in the area of thread communication), which might become useless for cross-platform developers.
How likely is it that there will be no emulation layer which maps old operating-specific message sending code to a cross-platform solution? Should application developers start now with reviews of existing code with new messaging implementations which are better suited for cross-platform operation?
PostMessage and SendMessage are Windows-specific - they are a part of the Windows API. If your program uses them then it is not cross-platform. You should probably rewrite the code that uses those functions.
Other operating system may have not a message queue at all. Windows specific code has to be isolated or removed to build cross-platoform applications. One of the reason they wrote the CLX library for Kylix is the VCL is so Windows-bound it can't be easily transformed into a cross-platform libray.
I suspect that you could implement your own Queue object, which could be implemented, in a platform specific manner. In Win32, it could wrap an underlying Win32 window handle, and in some other platform, some other resources could be consumed.
What if you start right now, by reducing your platform specific code, to certain units that encapsulate the functionality that you need. That means that you would need to avoid using PostMessage/SendMessage as a mechanism that you directly use.
To start with, imagine PostMessage, and SendMessage do not exist, and you need a way to create a queue. You could use sockets, for example, or named pipes, which exist on most platforms. You would need to write a bit more code, to do it this way.
On the QT libraries, they provide their own functionality to help application authors rewrite their C++ apps to use their functions instead of Win32 functions, so you could also try that approach. The QT function postEvent is an example of this. QT also provides signals and slots, and this is the more idiomatic way of doing notifications in their framework.
Perhaps the way of doing notifications in whatever new framework comes out with cross-platform Delphi might contain a whole new way of doing this. That's my hope.
I want to connect two PCs and have them communicate. Is there a nice component to do that? (preferably from TMS, or free), or do I just use standard C++ socket libraries?
What about sending data? Should I invent a simple protocol? TLV (type/length/value), where T is the message type and .. you get the picture...
Since you are using C++ Builder, you should really be using the Indy components, they are a nice well tested and easy to work with set of networking components... And they are already built into C++ Builder. If you are using C++ Builder, using Qt or boost can be really problematic (of course depending on C++ Builder version).
Indy components: http://www.indyproject.org/index.en.aspx
With Indy components you get all the components you need for basically every sort of network development you need, it is by far the most complete networking solution for C++Builder/Delphi that I have seen.
You might find this article interesting: Developing TCP/IP-based Server Applications using Indy Components [1] it shows examples in Delphi, but converting to C++ should be trivial.
Besides the Delphi in Depth [2] book is a good resource and contains samples in C++ as well.
About the developing your own protocol, it is almost impossible to answer that question with a definitive answer, it really depends on the requirements you have. Perhaps you should start by asking, is there an existing protocol that would work for me, before you end up, perhaps, reinventing the wheel.
[1] http://conferences.embarcadero.com/article/33256
[2] http://www.atozed.com/indy/book/index.en.aspx
You should look at Qt or Boost. (I personally prefer Qt's network API and documentation, but you may feel differently.)
And for something simple, why would you invent your own protocol? Just use HTTP. It's easy to work with and you can use all kinds of tools, not just your own code, to verify that everything is working properly.
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.
Is there any difference between using vcl components in Delphi and WinApi functions to create gui application.
#Azad I think there are 2 big differences: the first is the ease of use of the VCL that enables you to drag and drop controls on a form (window), change its properties and assign events, giving you high productivity in the development of the GUI.
The other big difference is the size of the final application, if you create an application using only WINAPI calls, your final application will be smaller than using the VCL.
I recommend you see the project KOL (KOL - Key Objects Library is a set of objects to develop power (but small) 32 bit Windows GUI applications using Delphi but without VCL (or Free Pascal). It is distributed free of charge, with source code.).
(source: kolmck.net)
Almost all real-world Delphi applications use the VCL, and also make OCCASIONAL direct calls to the Win32 API. The VCL framework calls Win32 calls, in the end, anyways. So, you will almost always be using both.
The guy who mentioned KOL is suggesting yet another "middle" layer, because going direct is sublimely painful.
Microsoft has (in historical order), MFC, and ATL for C++, and .NET for the C#/VB.net language, as "framework" layers that live between your application and the raw Win32 API, for their MS Visual Studio products.
People who write anything more complicated than Notepad.exe going straight to the "metal" (Win32 API raw) are rare. So, it's harder, it takes longer to learn, and do everything. And in the end, it's not significantly faster or better. If you really need to be small (like you are writing a virus) maybe you might want to go Win32 native.
The VCL is a complete framework wrapping the Windows API and insulating the developer from the gory details, making it so much easier to develop Delphi applications.
You gain big in productivity and compatibility over Windows version changes...
Well, sure, VCL requires a Borland compiler. The Win32 API works for any language. The point of using a GUI class library, like VCL, is to make the effort of creating a GUI enabled program easier. Doing so using only Win32 is quite punishing.
time, time and then even more time.
You use WinAPI to do things that VCL is not "able" to do.
I never liked components for winsock programming,I loved it in its natural way,but today my collegue told me to use Indy for my project.Could you tell me if Indy better alternative for my project?
-2 TCP servers,2 TCP clients.4 sockets total
-The project is a proxy.
And now the second question,I read daily that WSAASyncSelect is not good and that's predictable,it's from winsock 1.1.My question is: Suggest something better than AsyncSelect for winsock-by-hand.
Thank you.
My preference tends to lean on synapse for all of my socket work because of its light and easy to understand approach. It is not a component architecture, but a class architecture and implementation is generally as simple as copying one of the existing helper classes and modifying it to perform the exact steps needed. Synapse also has a great user community, and is being actively developed so get the latest changes from the svn snapshot (I believe its revision 98, the website has a zip of revision 38).
Yes, Indy is much better because it provides you with consistent abstraction of winsock communication. The difference is like creation windows using WinApi and simply using TForm.
Yes, Indy is better. So is ICS, or Synapse, or any of the other internet-related component sets. They handle all of the minutia and let you work on your application's actual functionality instead of wasting your time on the communications layer details. They're also much more well tested (because of the broader user base and wider range of hardware and operating systems) than your own code could ever hope to be.
NIH (Not Invented Here) is a really bad idea if there are well-constructed, well-maintained, and widely used alternatives available, especially when those alternatives are free with source (like Indy and ICS).