Geek Answers Handbook

Why are TClientSocket and TServerSocket deprecated and what should I use instead?

Iā€™m just starting out with Embarcadero RAD Studio 2010 after the life of Eclipse, Emacs, Visual Studio and Notepad :)

I jump into a rather large C ++ application (500,000 - 1,000,000 lines), which I found made extensive use of TClientSocket and TServerSocket. At first, the IDE made sure that TClientSocket was not found, but could still compile, and I scratched my head. Then I found out that it is no longer installed by default and marked as deprecated from the return path.

I tried to read about the subject, but did not find much information. My questions

  • Why are TClientSocket and TServerSocket deprecated?
  • How do they differ in how they function from WinSock and BSD sockets?
  • What is better to use instead and is there a quick replacement that would not include reviewing the entire application and changing wherever TClientSocket and TServerSocket are used? I would suggest that it will be mainly an internal work that has changed or?
+4
source share
2 answers

Deprecated because it is no longer supported. They are a wrapper for Winsock sockets, so the general internal mechanism is the same: "Create a listener, listen, receive, create a client handler thread by passing it a ServerClientSocket, the client thread reads and writes streams."

Perhaps you can try just importing the components - if you have a massive application for support, then this is certainly a way if it works.

Then there is another way: ((Use the Indy or Synapse components to create the "TClientSocket" and TServerSocket classes with identical members so that the legacy application works without significant changes.

+3
source

They are deprecated in favor of Indy sockets.

However, Indy sockets are blocked only. If your program uses blocking sockets, then this is normal, but if you use non-blocking sockets, as far as I know, you have only two options:

  • use streams plus block Indy sockets
  • use TClientSocket and TServerSocket

There are TTcpServer and TTcpClient components that have a switch between locking and non-locking. However, if you manage them in non-blocking mode, they simply do not work (basic operations are not performed using WSAEWOULDBLOCK), and there is no workaround.

Note for everyone who reads this, who might not know: even in the latest versions (as I write) you can still import them into the IDE by adding dclsocketsNNN.bpl to the list of development-time packages. They are, by default inactive.

Personally, I still use TClientSocket in non-blocking mode in production, it works very well (after fixing some errors, which is possible due to the fact that the full source is provided!)

0
source

More articles:


All Articles