Can someone please tell me where the TTcpClient and TTcpServer VCL components went in XE6 & XE7. I have an application that I am migrating from XE5 and it seems that these components have disappeared.
Thanks
James
In addition to Indy, some other network component options are:
- IP*works (non-blocking, I think)
- ICS (non-blocking)
- Synapse (blocking)
I use Synapse for simple TCP stuff. It's free, though you can make a
donation if you like it. If you decide to try it, get the latest trunk
(192) from the link below. The blocking model has some advantages, if
you give it a try.
http://sourceforge.net/p/synalist/code/HEAD/tree/
Joe
Studio.On 10/15/2014 11:39 AM, James Williams wrote:
>> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
>> James wrote:
>>
>>> So, what is it being replaced with?
>>
>> Nothing.
>>
>>> I hope not the IndyTcp Client & Server.
>>
>> Why?
> Because the Indy components are blocking components. If I open a TCPIP client, and I want to achieve a independant overlapped I/O operation, then this is not possible. I would have to first do either a read or write, wait for it to complete and then do the opposite write or read. In a full duplex system, this is non-idea. Unless I missed something with the Indy components. Additionally, I would be forced to place the Client & Server into their own threads, at the very start, which is not a big dea
l,
> but still.
>
> In my particular application, I have a service that will write out at regular controlled intervals. Every 25ms in my case. At the same time it may will initiate a read operation on the same connection resource if the last read operation that was requested at time t-25 has finished. Otherwise it skips that read for the current write interval. It does not wait for the read to return as the sender is allowed to send any interval. However, the server is required to responsd to the request the moment it
ar
> rives.
>
>
>>
>> --
>> Remy Lebeau (TeamB)
James wrote:
> Because the Indy components are blocking components.
That is your only complaint? See this portion of Indy's documentation:
http://www.indyproject.org/docsite/html/IntroIndy.html
{quote}
Indy is Blocking
Indy uses blocking socket calls. Blocking calls are much like reading and
writing to a file. When you read data, or write data, the function will not
return until the operation is complete. The difference from working with
files is that the call may take much longer as data may not be immediately
ready for reading or writing (It can only operate as fast as the network
or the modem can handle the data).
For example, to connect simply call the connect method and wait for it to
return. If it succeeds, it will return when it does. If it fails, it will
raise an exception.
----------
Blocking is NOT Evil
Blocking sockets have been repeatedly attacked with out warrant. Contrary
to popular belief, blocking sockets are not evil.
When Winsock was "ported" to Windows, a problem quickly arose. In Unix it
was common to fork (kind of like multi threading, but with separate processes
instead of threads). Unix clients and daemons would fork processes, which
would run, and use blocking sockets. Windows 3.x could not fork and did not
support multi threading. Using the blocking interface "locked" user interfaces
and made programs unresponsive. So asynchronous extensions were added to
WinSock to allow Windows 3.x with its shortcomings to use Winsock without
"locking" the main and only thread of a program. This however required a
different way of programming., and Microsoft and others vilified blocking
vehemently so as to mask the shortcomings of Windows 3.x.
Then along came Win32 which could properly multi-thread. But at this point,
everyone's mind had been changed (i.e. Developers believed blocking sockets
were evil), and it is hard to "backtrack" once a statement has been made.
So the continued vilification of blocking sockets continues.
In reality, blocking sockets are the ONLY way Unix does sockets. Blocking
sockets also offer other advantages, and are much better for threading, security,
and other aspects. Some extensions have been added for non-blocking sockets
in Unix. However they work quite differently than in Windows. They also are
not standard, and not in wide use. Blocking sockets under Unix still are
used in almost every case, and will continue to be so.
{quote}
> If I open a TCPIP client, and I want to achieve a independant overlapped
> I/O operation, then this is not possible.
Yes, it is. Move the TCP/IP client or the overlapped I/O to a separate thread.
If you want to use the client in the main UI thread (which is not advisable,
but allowed), use the TIdAntiFreeze component to avoid blocking the message
queue.
> I would have to first do either a read or write, wait for it to complete
and then
> do the opposite write or read.
You can do full duplex I/O with Indy. You just have to do the reading and
writing in separate threads, that's all.
> Additionally, I would be forced to place the Client & Server into their
own threads,
> at the very start, which is not a big deal, but still.
Not a big deal, and how Indy should be used. You really should not be doing
anything blocking in the main thread.
BTW, Indy TCP servers are already multi-threaded, so you don't have to put
a server in its own thread, because it runs its own threads internally.
> In my particular application, I have a service that will write out at
> regular controlled intervals.
A service is multi-threaded to begin with. So it is not a stretch to do
socket I/O in threads as well.
> Every 25ms in my case. At the same time it may will initiate a read operation
> on the same connection resource if the last read operation that was requested
> at time t-25 has finished. Otherwise it skips that read for the current
write
> interval. It does not wait for the read to return as the sender is allowed
to
> send any interval. However, the server is required to responsd to the
request
> the moment it arrives.
All the more reason to use Indy, actually. If you abort the read, the data
still exists in the socket when it does arrive, so you might end up with
a later read receiving older data. At least with Indy, you can simply do
the reading in a loop in its own thread, with a timeout if needed (which
is usually not preferred, just let it block until data arrives, but timeouts
are supported), and you can respond immediately to any message that arrives,
independant of whatever else the service/app is doing in other threads.
--
Remy Lebeau (TeamB)
> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> James wrote:
>
> > So, what is it being replaced with?
>
> Nothing.
>
> > I hope not the IndyTcp Client & Server.
>
> Why?
Because the Indy components are blocking components. If I open a TCPIP client, and I want to achieve a independant overlapped I/O operation, then this is not possible. I would have to first do either a read or write, wait for it to complete and then do the opposite write or read. In a full duplex system, this is non-idea. Unless I missed something with the Indy components. Additionally, I would be forced to place the Client & Server into their own threads, at the very start, which is not a big deal,
but still.
In my particular application, I have a service that will write out at regular controlled intervals. Every 25ms in my case. At the same time it may will initiate a read operation on the same connection resource if the last read operation that was requested at time t-25 has finished. Otherwise it skips that read for the current write interval. It does not wait for the read to return as the sender is allowed to send any interval. However, the server is required to responsd to the request the moment it ar
rives.
>
> --
> Remy Lebeau (TeamB)
According to the same page:
http://docwiki.embarcadero.com/RADStudio/XE7/en/Working_with_sockets_Index
<<<
Instead of Web.Win.Sockets, consider using the existing comparable RTL sockets solutions in the System.Win.ScktComp unit, such as:
TClientSocket
TClientWinSocket
TServerClientWinSocket
TServerSocket
TServerWinSocket
>>>
So, what is it being replaced with? I hope not the IndyTcp Client & Server.
> {quote:title=Borja Serrano wrote:}{quote}
> Hello James
>
> As you can see here:
>
> http://docwiki.embarcadero.com/RADStudio/XE7/en/Working_with_sockets_Index
>
> Web.Win.Sockets has been deprecated. You can still install the components building and installing the sample from:
>
> C:\Users\Public\Documents\Embarcadero\Studio\15.0\Samples\Object Pascal\VCL
>
> As it is a Delphi project if you have C++ Builder you will need to build it using "msbuild" from the RAD Studio command prompt:
>
> cd C:\Users\Public\Documents\Embarcadero\Studio\15.0\Samples\Object Pascal\VCL\InetWinSockets
> msbuild inetwinsockets.dproj
>
> Regards,
>
> --
> Borja Serrano
> Embarcadero Technical Support Engineer
Hello James
As you can see here:
http://docwiki.embarcadero.com/RADStudio/XE7/en/Working_with_sockets_Index
Web.Win.Sockets has been deprecated. You can still install the components building and installing the sample from:
C:\Users\Public\Documents\Embarcadero\Studio\15.0\Samples\Object Pascal\VCL
As it is a Delphi project if you have C++ Builder you will need to build it using "msbuild" from the RAD Studio command prompt:
cd C:\Users\Public\Documents\Embarcadero\Studio\15.0\Samples\Object Pascal\VCL\InetWinSockets
msbuild inetwinsockets.dproj
Regards,
--
Borja Serrano
Embarcadero Technical Support Engineer
Mega Search
Sign Up 
