Indy10.6.0.5040 receive fails on Win 7 OS since upgrading to XE5 C++Builder

Since upgrading from XE2 to XE5 C++ Builder, using a project successfully compiled and running under XE2 (Indy 10.5.0...) when compiled under XE5 (Indy 10.6.0.5040) will work on transmitting MCast data to devices but
will not receive the returned data from the OS. Wireshark verifies that the expected data was received by the NIC OK. However, using, for instance, RcvByteCnt = IdIPMCastServer1->Binding->Receive(RecvBuffer); after the discovery request, results in a 'Socket error: connection timeout 10060' after the 2 second receive time out. Devices returned data to the request in under 200 millisec . If an MCastClient is used with an OnRead event, the event is never triggered. No changes were made to the before compili
ng it with XE5 (other than appropriate directory changes). All socket operations work except returning received data to the app. A Simple Ping project to a device works at the NIC level but due to a bug in Indy10 a 'message too long' is returned. I next built a small Echo app to run against an echo server and it works but there appears to be no method to retrieve the returned echo data at the app level. I might add that the XE2 compiled program from my other system works on the XE5 installed system with n
o problems.


Any ideas would be appreciated. Surely someone else has seen this problem since indy10 is used a lot.

Thank you
Dave Hendershot
0
Dave
2/6/2014 8:25:51 PM
embarcadero.cppbuilder.socket 566 articles. 0 followers. Follow

16 Replies
1502 Views

Similar Articles

[PageSpeed] 22
Get it on Google Play
Get it on Apple App Store

Dave wrote:

> However, using, for instance,
> RcvByteCnt = IdIPMCastServer1->Binding->Receive(RecvBuffer);
> after the discovery request, results in a 'Socket error: connection
> timeout 10060' after the 2 second receive time out.

TIdSocketHandle::Receive() directly calls the socket API recv() function. 
 If that is not returning data then the OS is not delivering the network 
data to the socket, such as if the socket is bound to an IP/Port that does 
not match the destination of the netwotk data, or the socket is not subscribed 
to the multicast group.

--
Remy Lebeau (TeamB)
0
Remy
2/6/2014 11:21:36 PM
> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> Dave wrote:
> 
> > However, using, for instance,
> > RcvByteCnt = IdIPMCastServer1->Binding->Receive(RecvBuffer);
> > after the discovery request, results in a 'Socket error: connection
> > timeout 10060' after the 2 second receive time out.
> 
> TIdSocketHandle::Receive() directly calls the socket API recv() function. 
>  If that is not returning data then the OS is not delivering the network 
> data to the socket, such as if the socket is bound to an IP/Port that does 
> not match the destination of the netwotk data, or the socket is not subscribed 
> to the multicast group.
> 
> --
> Remy Lebeau (TeamB)
Remy,
Thank you for your response. I delayed getting back to you because I wanted to develop an MCast server on the XE2 system and an MCast client on the XE5 system. After much digging I found that if I send an MCast message to the XE2 client using UDP port 8888, the client does not receive the message in the OnRead handler. If I change the port on both ends to 8889 the client will get the data in the OnRead handler. Monday I will reverse the roles of the two systems making the XE5 system the server and the XE2
 system the client. I will post the results Monday afternoon.
0
Dave
2/7/2014 8:10:43 PM
Dave wrote:

> After much digging I found that if I send an MCast message to the XE2
> client using UDP port 8888, the client does not receive the message in
> the OnRead handler. If I change the port on both ends to 8889 the client
> will get the data in the OnRead handler.

Sounds like port 8888 is likely being blocked by a firewall/router.

--
Remy Lebeau (TeamB)
0
Remy
2/7/2014 8:41:16 PM
> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> Dave wrote:
> 
> > After much digging I found that if I send an MCast message to the XE2
> > client using UDP port 8888, the client does not receive the message in
> > the OnRead handler. If I change the port on both ends to 8889 the client
> > will get the data in the OnRead handler.
> 
> Sounds like port 8888 is likely being blocked by a firewall/router.
> 
> --
> Remy Lebeau (TeamB)
Remy,

The link between the two system is through a hub and does not include a router and the firewalls are turned off on both systems. Use of any port number in the range of 8880 to 8890, EXCEPT 8888, will work with the XE5 generated program. I reversed the roles of the two systems making the system with XE2 the client and the system with XE5 the Server. The XE2 system program will receive and field all MCast transmissions sent to port 8888 from the system with XE5. The conclusion is that Indy10.6.0.5040 and 10
.6.0.5070 contain a bug that blocks reception of MCast messages to port 8888. According to the Wikipedia list of port usage, port 8888 is officially assigned to 'NewsEdge server', what ever that is. I work with PLCs (Programmeable Logic Controllers) and they are programmed at the FW level to respond to MCast messages on port 8888. The problem found in XE5 in using this port has stopped the development upgrade from XE2 to XE5. This upgrade to XE5 is a requirement for me to continue to stay current in my te
sting development.

Thanks,
Dave
0
Dave
2/10/2014 12:42:48 PM
> {quote:title=Dave Hendershot wrote:}{quote}
> > {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> > Dave wrote:
> > 
> > > After much digging I found that if I send an MCast message to the XE2
> > > client using UDP port 8888, the client does not receive the message in
> > > the OnRead handler. If I change the port on both ends to 8889 the client
> > > will get the data in the OnRead handler.
> > 
> > Sounds like port 8888 is likely being blocked by a firewall/router.
> > 
> > --
> > Remy Lebeau (TeamB)
> Remy,
> 
> The link between the two system is through a hub and does not include a router and the firewalls are turned off on both systems. Use of any port number in the range of 8880 to 8890, EXCEPT 8888, will work with the XE5 generated program. I reversed the roles of the two systems making the system with XE2 the client and the system with XE5 the Server. The XE2 system program will receive and field all MCast transmissions sent to port 8888 from the system with XE5. The conclusion is that Indy10.6.0.5040 and 
10.6.0.5070 contain a bug that blocks reception of MCast messages to port 8888. According to the Wikipedia list of port usage, port 8888 is officially assigned to 'NewsEdge server', what ever that is. I work with PLCs (Programmeable Logic Controllers) and they are programmed at the FW level to respond to MCast messages on port 8888. The problem found in XE5 in using this port has stopped the development upgrade from XE2 to XE5. This upgrade to XE5 is a requirement for me to continue to stay current in my 
testing development.
> 
> Thanks,
> Dave
Additional info. There are no other programs running that are using port 8888 on the XE5 system.
0
Dave
2/10/2014 1:16:18 PM
> {quote:title=Dave Hendershot wrote:}{quote}
> > {quote:title=Dave Hendershot wrote:}{quote}
> > > {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> > > Dave wrote:
> > > 
> > > > After much digging I found that if I send an MCast message to the XE2
> > > > client using UDP port 8888, the client does not receive the message in
> > > > the OnRead handler. If I change the port on both ends to 8889 the client
> > > > will get the data in the OnRead handler.
> > > 
> > > Sounds like port 8888 is likely being blocked by a firewall/router.
> > > 
> > > --
> > > Remy Lebeau (TeamB)
> > Remy,
> > 
> > The link between the two system is through a hub and does not include a router and the firewalls are turned off on both systems. Use of any port number in the range of 8880 to 8890, EXCEPT 8888, will work with the XE5 generated program. I reversed the roles of the two systems making the system with XE2 the client and the system with XE5 the Server. The XE2 system program will receive and field all MCast transmissions sent to port 8888 from the system with XE5. The conclusion is that Indy10.6.0.5040 an
d 10.6.0.5070 contain a bug that blocks reception of MCast messages to port 8888. According to the Wikipedia list of port usage, port 8888 is officially assigned to 'NewsEdge server', what ever that is. I work with PLCs (Programmeable Logic Controllers) and they are programmed at the FW level to respond to MCast messages on port 8888. The problem found in XE5 in using this port has stopped the development upgrade from XE2 to XE5. This upgrade to XE5 is a requirement for me to continue to stay current in m
y testing development.
> > 
> > Thanks,
> > Dave
> Additional info. There are no other programs running that are using port 8888 on the XE5 system.
Further investigation using wireshark shows another issue when compared to the operation of XE2 compiled project. Using the simple MCast program, with XE2 compiled code, activation of the IdIPMcastServer will cause an IGMP 'V3 Membership report / Join group 224.0.27.80' on the link and a 'leave group' message when Active is set to false. XE5 compiled code of the same simple program does not initiate the IGMP Join or Leave group message when using IdIPMCastServer. If an IdIPMCastClent is activated the prop
er Join is sent on the link and 'Leave' is generated when Active is set to false in the XE5 compiled project.
0
Dave
2/10/2014 6:40:47 PM
Dave wrote:

> The conclusion is that Indy10.6.0.5040 and 10.6.0.5070 contain a bug
> that blocks reception of MCast messages to port 8888.

I assure you, there is no such port-specific bug like you describe.  Indy 
merely takes whatever port you give it and passes it along to the underlying 
OS socket API.  So it has to be the OS itself, not Indy, that is filtering 
the messages outside of Indy.

> According to the Wikipedia list of port usage, port 8888 is officially 
assigned
> to 'NewsEdge server', what ever that is. I work with PLCs (Programmeable
> Logic Controllers) and they are programmed at the FW level to respond to
> MCast messages on port 8888. The problem found in XE5 in using this port
> has stopped the development upgrade from XE2 to XE5.

AFAIK, Indy's Multicast components have not changed between XE2 and XE5. 
 Something else is going on.  YOu will just have to step through the Indy 
components in both versions and see what is really going on under-the-hood 
and look for any API differences between them.

--
Remy Lebeau (TeamB)
0
Remy
2/10/2014 8:18:04 PM
Dave wrote:

> Further investigation using wireshark shows another issue when
> compared to the operation of XE2 compiled project. Using the
> simple MCast program, with XE2 compiled code, activation of
> the IdIPMcastServer will cause an IGMP 'V3 Membership report /
> Join group 224.0.27.80' on the link and a 'leave group' message
> when Active is set to false. XE5 compiled code of the same simple
> program does not initiate the IGMP Join or Leave group message
> when using IdIPMCastServer. If an IdIPMCastClent is activated the
> proper Join is sent on the link and 'Leave' is generated when Active
> is set to false in the XE5 compiled project.

In the latest Indy SVN version, I see that TIdIPMCastClient calls TIdSocketHandle.AddMulticastMembership() 
on each Binding socket that it creates, but I see no such call in TIdIPMCaseServer. 
 So I reviewed the XE2 version and see that TIdIPMCastServer did used to 
make that same call.  It was intentionally removed in 2012 somewhere in the 
XE3/XE4 timeframe.  Here is the checkin comment:

{quote}
Updated TIdIPMCastServer to no longer subscribe to its own multicast group. 
 Causes duplicate packet traffic on the network.  Only clients should be 
subscribing to the group.
{quote}

--
Remy Lebeau (TeamB)
0
Remy
2/10/2014 8:29:28 PM
> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> Dave wrote:
> 
> > The conclusion is that Indy10.6.0.5040 and 10.6.0.5070 contain a bug
> > that blocks reception of MCast messages to port 8888.
> 
> I assure you, there is no such port-specific bug like you describe.  Indy 
> merely takes whatever port you give it and passes it along to the underlying 
> OS socket API.  So it has to be the OS itself, not Indy, that is filtering 
> the messages outside of Indy.
> 
> > According to the Wikipedia list of port usage, port 8888 is officially 
> assigned
> > to 'NewsEdge server', what ever that is. I work with PLCs (Programmeable
> > Logic Controllers) and they are programmed at the FW level to respond to
> > MCast messages on port 8888. The problem found in XE5 in using this port
> > has stopped the development upgrade from XE2 to XE5.
> 
> AFAIK, Indy's Multicast components have not changed between XE2 and XE5. 
>  Something else is going on.  YOu will just have to step through the Indy 
> components in both versions and see what is really going on under-the-hood 
> and look for any API differences between them.
> 
> --
> Remy Lebeau (TeamB)
I admit that this is a weird situation and I know there is a difference 'under the hood'. I've never had to step through the Indy code, even though I have tried without success. I'll figure it out somehow and when I do I'll post the results. If I can figure out why no 'join' is issued when the MCast Server is enabled I'll have come a long way. Thank you.
0
Dave
2/11/2014 12:31:14 PM
> {quote:title=Dave Hendershot wrote:}{quote}
> > {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> > Dave wrote:
> > 
> > > The conclusion is that Indy10.6.0.5040 and 10.6.0.5070 contain a bug
> > > that blocks reception of MCast messages to port 8888.
> > 
> > I assure you, there is no such port-specific bug like you describe.  Indy 
> > merely takes whatever port you give it and passes it along to the underlying 
> > OS socket API.  So it has to be the OS itself, not Indy, that is filtering 
> > the messages outside of Indy.
> > 
> > > According to the Wikipedia list of port usage, port 8888 is officially 
> > assigned
> > > to 'NewsEdge server', what ever that is. I work with PLCs (Programmeable
> > > Logic Controllers) and they are programmed at the FW level to respond to
> > > MCast messages on port 8888. The problem found in XE5 in using this port
> > > has stopped the development upgrade from XE2 to XE5.
> > 
> > AFAIK, Indy's Multicast components have not changed between XE2 and XE5. 
> >  Something else is going on.  YOu will just have to step through the Indy 
> > components in both versions and see what is really going on under-the-hood 
> > and look for any API differences between them.
> > 
> > --
> > Remy Lebeau (TeamB)
> I admit that this is a weird situation and I know there is a difference 'under the hood'. I've never had to step through the Indy code but I will now. I'll figure it out somehow and when I do I'll post the results. If I can figure out why no 'join' is issued when the MCastServer is enabled I'll have come a long way. Thank you.

New info: 0930 02/11/14
I just stepped through the source code for the IdIPMCastServer (10.6.0.5070) and compared it the Indy version 10.5.0.... and found that the 10.6.0.5040 does not have a line of code such as 'Bindings.AddMulticastMembership(FMulticastGroup);' in the IdIPMCastServer source as does the same source code in 10.5.0..... The IdIPMCastClient source code DOES contain the AddMulticastMembership() function in 10.6.0.5040. So there is a difference right there. This line of code, (compared to the IdIPMCastClient code),
 should be in the function TIdIPMCastServer.GetBinding: TIdSocketHandle; just after the FBinding.Bind; line of code. I did find out by experimentation, that in my project code, in order to have a 'membership report' sent on the link, I had to add the following code after the IdIPMCastServer was set to active: IdIPMCastServer1->Binding->AddMulticastMembership("224.0.27.80"). That caused a IGMP 'membership report' to be sent even though what is sent is IGMPV2 not IGMPV3. The long and short is that the Indy 
code did change between 10.5.0.... and 10.6.0.5040. I should not have to add the line of code to my project in order to get a 'membership to be sent. When I do add this line in my code, an IGMPV2 packet is sent instead of the IGMPV3 packet.  I should see the following in the transmitted packet when a membership report is sent '(dest)224.0.0.22  IGMP  V3 Membership Report / Join Group 224.0.27.80 for any sources' but don't. Update later, maybe.
0
Dave
2/11/2014 2:33:01 PM
> {quote:title=Dave Hendershot wrote:}{quote}
> > {quote:title=Dave Hendershot wrote:}{quote}
> > > {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> > > Dave wrote:
> > > 
> > > > The conclusion is that Indy10.6.0.5040 and 10.6.0.5070 contain a bug
> > > > that blocks reception of MCast messages to port 8888.
> > > 
> > > I assure you, there is no such port-specific bug like you describe.  Indy 
> > > merely takes whatever port you give it and passes it along to the underlying 
> > > OS socket API.  So it has to be the OS itself, not Indy, that is filtering 
> > > the messages outside of Indy.
> > > 
> > > > According to the Wikipedia list of port usage, port 8888 is officially 
> > > assigned
> > > > to 'NewsEdge server', what ever that is. I work with PLCs (Programmeable
> > > > Logic Controllers) and they are programmed at the FW level to respond to
> > > > MCast messages on port 8888. The problem found in XE5 in using this port
> > > > has stopped the development upgrade from XE2 to XE5.
> > > 
> > > AFAIK, Indy's Multicast components have not changed between XE2 and XE5. 
> > >  Something else is going on.  YOu will just have to step through the Indy 
> > > components in both versions and see what is really going on under-the-hood 
> > > and look for any API differences between them.
> > > 
> > > --
> > > Remy Lebeau (TeamB)
> > I admit that this is a weird situation and I know there is a difference 'under the hood'. I've never had to step through the Indy code but I will now. I'll figure it out somehow and when I do I'll post the results. If I can figure out why no 'join' is issued when the MCastServer is enabled I'll have come a long way. Thank you.
> 
> New info: 0930 02/11/14
> I just stepped through the source code for the IdIPMCastServer (10.6.0.5070) and compared it the Indy version 10.5.0.... and found that the 10.6.0.5040 does not have a line of code such as 'Bindings.AddMulticastMembership(FMulticastGroup);' in the IdIPMCastServer source as does the same source code in 10.5.0..... The IdIPMCastClient source code DOES contain the AddMulticastMembership() function in 10.6.0.5040. So there is a difference right there. This line of code, (compared to the IdIPMCastClient code
), should be in the function TIdIPMCastServer.GetBinding: TIdSocketHandle; just after the FBinding.Bind; line of code. I did find out by experimentation, that in my project code, in order to have a 'membership report' sent on the link, I had to add the following code after the IdIPMCastServer was set to active: IdIPMCastServer1->Binding->AddMulticastMembership("224.0.27.80"). That caused a IGMP 'membership report' to be sent even though what is sent is IGMPV2 not IGMPV3. The long and short is that the Ind
y code did change between 10.5.0.... and 10.6.0.5040. I should not have to add the line of code to my project in order to get a 'membership to be sent. When I do add this line in my code, an IGMPV2 packet is sent instead of the IGMPV3 packet.  I should see the following in the transmitted packet when a membership report is sent '(dest)224.0.0.22  IGMP  V3 Membership Report / Join Group 224.0.27.80 for any sources' but don't. Update later, maybe.

Update: 1040 2/11/14
In my test program, I added 'IdIPMCastServer1->Binding->AddMulticastMembership("224.0.27.80");' to my code just before setting IdIPMCastServer1->Active = true; Activated the server thread, the proper 'join' transmission was sent on the link, sent out the MCast query, and was able to receive that data back using 'ByteCount = IdIPMCastServer1->Binding->Receive(RecvData);'. Conclusion, based on finding in previous post, the Indy 10.6.0.5040 code is a problem. I should not have to add the line of code I did i
n order to have my project work. What say ye?
0
Dave
2/11/2014 3:45:15 PM
Dave wrote:

> I just stepped through the source code for the IdIPMCastServer
> (10.6.0.5070) and compared it the Indy version 10.5.0.... and
> found that the 10.6.0.5040 does not have a line of code such as
> 'Bindings.AddMulticastMembership(FMulticastGroup);' in the
> IdIPMCastServer source as does the same source code in 10.5.0.....

Yes, and that change was intentional.  Having the server subscribe to its 
own multicast group was causing duplicated multicast packets to be sent/received.

--
Remy Lebeau (TeamB)
0
Remy
2/11/2014 6:41:54 PM
Remy wrote:

> Yes, and that change was intentional.  Having the server subscribe to
> its own multicast group was causing duplicated multicast packets to be
> sent/received.

Also, if you look at various online demos of multicasting, the *sender* does 
not subscribe to its own multicast group, only *receivers* subscribe to the 
group. 

--
Remy Lebeau (TeamB)
0
Remy
2/11/2014 6:53:31 PM
> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> Remy wrote:
> 
> > Yes, and that change was intentional.  Having the server subscribe to
> > its own multicast group was causing duplicated multicast packets to be
> > sent/received.
> 
> Also, if you look at various online demos of multicasting, the *sender* does 
> not subscribe to its own multicast group, only *receivers* subscribe to the 
> group. 
> 
> --
> Remy Lebeau (TeamB)

OK and thanks, and I can handle that, but where do I find the change information that alerts a coder to that change? Also, the other issue that I have (had) with the IdIPMCastClient not receiving MCast message on port 8888, I ended up adding the following code line in my project after the IdIPMCastClient->Active = true; - 'IdIPMCastClient1->Bindings->Items[0]->SetSockOpt(Id_SOL_SOCKET,Id_ SO_REUSEADDR, Id_SO_True)'- to get the project to receive the MCast date sent to port 8888. Why it picked on port 8888
 and not other ports is beyond me. In researching the 10.6.0.4050 source and comparing the 10.5.0.... source, line 197 in the IdIPMCastClient.pas code version 10.5.0.... function TIdIPMCastClient.GetBinding: TIdSocketHandle, is not in the same function 10.6.0.5040 source code module of the same name. I suppose this was intentional as well. I read through the revision files with XE5 but saw nothing concerning these changes. Maybe I didn't look in the right place for information but I did search a lot for a
nswers.
0
Dave
2/11/2014 7:18:46 PM
Dave wrote:

> where do I find the change information that alerts a coder to that change?

There wasn't any public alert for that change, only the comment when the 
change was checked in to Indy's SVN:

{quote}
Revision: 4854
Author: Indy-RemyLebeau
Date: Monday, October 29, 2012 2:13:12 PM
Message:
Updated TIdIPMCastServer to no longer subscribe to its own multicast group. 
 Causes duplicate packet traffic on the network.  Only clients should be 
subscribing to the group.
----
Modified : /trunk/Lib/Core/IdIPMCastServer.pas
{quote}

> Also, the other issue that I have (had) with the IdIPMCastClient not receiving
> MCast message on port 8888, I ended up adding the following code line in my
> project after the IdIPMCastClient->Active = true; -
> 'IdIPMCastClient1->Bindings->Items[0]->SetSockOpt(Id_SOL_SOCKET,Id_
> SO_REUSEADDR, Id_SO_True)'- to get the project to receive the MCast
> date sent to port 8888.

TIdIPMCaseServer has a ReuseSocket property for handling SO_REUSEADDR.  It 
is set to rsOSDependent by default, which enables SO_REUSEADDR only on *Nix-based 
systems.  You can set it to rsTrue instead to force it enabled on all platforms.

> In researching the 10.6.0.4050 source and comparing the 10.5.0.... source,
> line 197 in the IdIPMCastClient.pas code version 10.5.0.... function
> TIdIPMCastClient.GetBinding: TIdSocketHandle, is not in the same function
> 10.6.0.5040 source code module of the same name.
> I suppose this was intentional as well.

That change was made way back in 2011 between XE3/4 when SO_REUSEADDR logic 
was moved from various components into the TIdSocketHandle class.

> I read through the revision files with XE5 but saw nothing concerning these
> changes.

Delphi does not ship with any "revision files" for Indy changes.

--
Remy Lebeau (TeamB)
0
Remy
2/11/2014 8:24:00 PM
> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> Dave wrote:
> 
> > where do I find the change information that alerts a coder to that change?
> 
> There wasn't any public alert for that change, only the comment when the 
> change was checked in to Indy's SVN:
> 
> {quote}
> Revision: 4854
> Author: Indy-RemyLebeau
> Date: Monday, October 29, 2012 2:13:12 PM
> Message:
> Updated TIdIPMCastServer to no longer subscribe to its own multicast group. 
>  Causes duplicate packet traffic on the network.  Only clients should be 
> subscribing to the group.
> ----
> Modified : /trunk/Lib/Core/IdIPMCastServer.pas
> {quote}
> 
> > Also, the other issue that I have (had) with the IdIPMCastClient not receiving
> > MCast message on port 8888, I ended up adding the following code line in my
> > project after the IdIPMCastClient->Active = true; -
> > 'IdIPMCastClient1->Bindings->Items[0]->SetSockOpt(Id_SOL_SOCKET,Id_
> > SO_REUSEADDR, Id_SO_True)'- to get the project to receive the MCast
> > date sent to port 8888.
> 
> TIdIPMCaseServer has a ReuseSocket property for handling SO_REUSEADDR.  It 
> is set to rsOSDependent by default, which enables SO_REUSEADDR only on *Nix-based 
> systems.  You can set it to rsTrue instead to force it enabled on all platforms.
> 
> > In researching the 10.6.0.4050 source and comparing the 10.5.0.... source,
> > line 197 in the IdIPMCastClient.pas code version 10.5.0.... function
> > TIdIPMCastClient.GetBinding: TIdSocketHandle, is not in the same function
> > 10.6.0.5040 source code module of the same name.
> > I suppose this was intentional as well.
> 
> That change was made way back in 2011 between XE3/4 when SO_REUSEADDR logic 
> was moved from various components into the TIdSocketHandle class.
> 
> > I read through the revision files with XE5 but saw nothing concerning these
> > changes.
> 
> Delphi does not ship with any "revision files" for Indy changes.
> 
> --
> Remy Lebeau (TeamB)

OK. It was a very interesting journey, but I learned a lot and got back into what I enjoy the most- digging for answers. I ran my project through a full operation and it is running satisfactorily. Thanks for putting up with me.
0
Dave
2/11/2014 8:32:51 PM
Reply:

Similar Artilces:

Upgrade 7.0 to 7.5 fails
Hi all, I'm just trying to upgrade my PD Version 7.0.0.507 to 7.5, I downloaded the files, when I start "PowerDesigner_75.exe" (21.342KB) it starts a lot of unpacking and so on, and just when it should start the "real" installation, it complains about "no previous version 7 found on yur computer". Has anyone had a similar effect or does someone know where PD "looks for" the previous version ? Just to mention it again: 7.0 *IS* installed - and working. Any help appreciated... Matt Replying to my own post here, just to let you ...

10.0.6 & 10.0.7 updates will not properly install in C++ Builder 2009
Okay, it looks like there is a problem with C++ Builder 2009 IntraWeb updates. I ran my Delphi 2009 (we bought both) and the updates definately installed there (log on standalone server shows IntraWeb version 10.0.7.. source code shows 10.0.7 being used). Everyone who has C++ Builder 2009 and has installed the new updates I need you to look at your standalone server log or your Source code on your intraweb browser, I'm betting you will see 10.0.0 instead of 10.0.7. Is there anyone at Embarcadero who can test to see if this is true? Have the updates been fully tested to make sure t...

Upgrade to ASA 7.0.0.313 and PowerBuilder 6.0
Hi ya all, I had a quick question. We recently upgraded from Sybase SQL ANYWHERE 5.5 TO ASA 7.0.0.313. When I run a script from PowerBuilder 6.0 and try to pass date arguments to the datawindow object, the date arguments get corrupted, i.e. they are no longer date arguments when the dwo receives them. They appear as funny looking characters that don't make any sense. In my dwo I am using various subqueries. One thing that is bizarre is that if I take all subqueries out of my dwo, the date arguments passed to the datawindow object work fine. It is only when I use a subquery that the ...

Connection of PB 6.0 to SQL Server 7.0 & Version B/W PB 6.0 and PB 7.0
Can anyone tell me about connecting PB 6.0 to SQL Server 7.0. Please remember we are not planning to upgrade both software. When I was trying to connect PB 6.0 to SQL Server 7.0, error occurred " SQLSTAT 1003". OS=NT 4.0 Server PB=6.0 Enterprise Edition SQL SERVER=7.0 Corporate Edition I also want to know the versions between PB 6.0 to PB 7.0 If your are using the ODBC, which I assume you are, include Disablebind=1 in your DBParm. If your deployment environment is also NT, you will have to turn SQLSPY=1 using PFC services. Autocommit=FALSE and SetTransObject() ra...

Upgrade from gw 6.5 to 7.0 linux fails
I have read various articles how to upgrade from groupwise 6.5 to 7.0 and i have make my test with manually upgrade with succesful. But when i have to upgrade the system in a product enviroment i can login to the tree but when i can connect to the domain consoleone freeze , i can create a user in my nds tree but without the groupwise extension, i i create a user with the groupwise extension consoleone freeze ,the snapins is upgrade to 7.0 but the system is 6.5 , can i reverse the snapins to 6.5 ? The Po, Mta and Gwia are running fine and the user can login to the post office ,send ...

Help me about connecting PB 6.0 to SQL Server 7.0 & Versions B/W PB 6.0 and PB 7.0
Can anyone tell me about connecting PB 6.0 to SQL Server 7.0. Please remember we are not planning to upgrade both software. When I was trying to connect PB 6.0 to SQL Server 7.0, error occurred " SQLSTAT 1003". OS=NT 4.0 Server PB=6.0 Enterprise Edition SQL SERVER=7.0 Corporate Edition I also want to know the versions between PB 6.0 to PB 7.0 I don't believe this is going to be possible without at least upgrading to the latest maintenance release of 6.x. On Mon, 23 Aug 1999 00:59:56 -0700, in powersoft.public.powerbuilder.database Abdul Lateef <abdul_lat...

Upgrading 7.0.0 to 7.0.1
I am trying to solve a PHP problem with 7.0.0 and have been told that the problem is fixed in 7.0.1 and that I should upgrade. The problem is HOW do I upgrade from 7.0.0 to 7.0.1. We have a registered copy of 7.0.0 which has been patched to build 477, but there is no downloadable upgrade to 7.0.1 on the web site. I have downloaded both the 7.0.1 1138 and 1161 EBF's but neither will apply themselves to our current build. Does anybody have any idea how to do this. Andrew Niven >The problem is HOW do I upgrade from 7.0.0 to 7.0.1. We have >a registered copy o...

C
Hello, We are currently running the Agent version: Client Agent: 6.4.2.253 Detection Agent: 6.4.2.253 Patch Management Server: 6.4.2.1378 Control Panel: 6.4.2.253 Notification Manager: 6.4.2.252 If i deploy the new patch: "C - ZENworks Patch Management Agent Upgrade for Windows from 6.0 or higher to 6.4.2.378" it is installed fine (status: green), but after a reboot of this workstation the Client Agent is not changed and still 6.4.2.253. I checked GravitixService.exe and DAgent.exe, and these versions are still 6.4.2.253. So why is...

Is it worth to upgrade from 6.0 to 7.0 ?
This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C14BEE.14C4B560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,. We have a few clients currently on ASA6.0, I would like to find out is = it worth at all to move to 7.0 ? Thanks ------=_NextPart_000_0022_01C14BEE.14C4B560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-e...

Upgrading 4.0 to 5.0 then 6.0 or go straight to 6.0
Hi All, I think the subject speaks for itself Thanks in advance Mustafa You should have no trouble going straight to 6 from 4. Once you do this, go back and get rid of the obsolete function calls. -- Regards, Millard[TeamPowersoft] -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ mf3@gatesys.com Co-Author of PowerBuilder 5.0: Object Oriented Design and Development McGraw-Hill, ISBN 0-07-024469-3 Co-Author of PFC Professional Reference (Block, Brown, Gasin, Green & Tauber) McGraw-Hill, 0-07-913267-7 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

Upgrading 7.0.0 database to 7.0.3
I have a database that was created in 7.0.0. I now use 7.0.3.2079. I'm having trouble upgrading the database. First, contrary to the help file, there was no upgrade utility in Sybase Central. At least, I can't find it. So I opened ISQL and ran the statement, 'alter database upgrade'. This caused the following message to pop up: ISQL Error Line 1, Column 16 Could not execute statement. ASA Error -198: Primary key for row in table 'SYSCAPABILITYNAME' is referenced in another table. The ISQL Messages window contained the following: Creating ...

Failed NetWare 6.0 to 6.5 upgrade
I recently upgraded two NetWare 6.0 SP5 servers (same tree & context) to NetWare 6.5; one server was successfully upgraded using CD's in the local drive. The other server was updated using the remote upgrade option, and went well until the first reboot. When I checked this server, it would not start. Following the "downed server upgrade" (boot from NW65OS CD, select "manual", at R: prompt type "install /?" for choices, selected downed server upgrade) appeared to work, but now the server partially starts and abends. This server is used ...

Netware 6.0 to 6.5 Upgrade fails
Hi, I am having trouble starting the upgrade to Netware 6.5 using the Java Console & the remote upgrade. I am using a NetWare 6.5 with SP2 overlay CD. This is happening on both servers that I have attempted to upgrade, one is NW6.0 SP4 & the other is NW6.0 SP5. Both servers are running Java 1.4 SP3, is there a problem upgrading servers running this version of Java?? Error log from remote upgrade: Driver Fatal: java.lang.NullPointerException at com.novell.application.install.InstallProduct.preSelectionAnalyze (InstallProduct.java:888) at com.novell.application...

Smoke [5.13.6] v5.13.6-97-g422d053 FAIL(M) cygwin_nt-5.1 1.7.7(0.230/5/3) (x86/2 cpu)
Automated smoke report for 5.13.6 patch 422d053b400e15f0154beccd0cbcd57e26d0a23a v5.13.6-97-g422d053 philips: Genuine Intel(R) CPU T2300 @ 1.66GHz(~1663 MHz) (x86/2 cpu) on cygwin_nt-5.1 - 1.7.7(0.230/5/3) using gcc version 4.3.4 20090804 (release) 1 smoketime 30 minutes 5 seconds (average 30 minutes 5 seconds) Summary: FAIL(M) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = ...

Web resources about - Indy10.6.0.5040 receive fails on Win 7 OS since upgrading to XE5 C++Builder - embarcadero.cppbuilder.socket

C++Builder - Wikipedia, the free encyclopedia
owned by Embarcadero Technologies , for writing programs in the C++ programming language targeting Windows and OS X . C++Builder combines the ...

Embarcadero C++Builder XE5 Delivers New iOS Support
Embarcadero Technologies delivered C++Builder XE5, which enables C++ developers to build native Windows, Mac and iOS apps in C++.

Sneak Preview: Delphi 2011 is Delphi XE
... next three weeks, we'll be previewing some of the great new things that are coming in the upcoming versions of RAD Studio XE, Delphi XE, C++Builder ...

VCL versus CLX
This paper will look at the new CLX library (pronounced clicks ) that ships with all versions of Kylix and also with Delphi 6 and later. Delphi ...

DevExpress Industry Recognition - Recent Awards
Feature-Complete Components, IDE Tools, and Business Application Frameworks for Visual Studio, Delphi and C++Builder

Visual Studio 11 Beta Today
Feature-Complete Components, IDE Tools, and Business Application Frameworks for Visual Studio, Delphi and C++Builder

Products
... development product (Elevate Web Builder). Our first-generation database engine product, DBISAM, is a good fit for Delphi and C++Builder application ...

C++Builder XE3 - Rapid visual C++ development environment
C++Builder XE3 is the fastest way to create high performance native applications for Windows 8 and Mac OS X Mountain Lion, including Retina display ...

Programming with RAD Studio Index
Show: Delphi C++ Display Preferences From RAD Studio XE3 Jump to: navigation , search Go Up to Delphi Developer's Guide This section describes ...

Visual Build Professional Help
Contents - Index Introduction Overview Why Visual Build? New Features Version 4 Version 5 Version 6 Version 7 Version 8 License Agreement Installation ...

Resources last updated: 1/13/2016 12:44:46 AM