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

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)

> {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.

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)

> {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

> {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.

> {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.

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)

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)

> {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.

> {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.

> {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?

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)

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)

> {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.

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)

> {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.