Charmed Quark Systems, Ltd. - Support Forums and Community
Clarifying socket binding strategies - Printable Version

+- Charmed Quark Systems, Ltd. - Support Forums and Community (
+-- Forum: General Discussion (
+--- Forum: Driver Development (
+--- Thread: Clarifying socket binding strategies (/showthread.php?tid=8934)

Pages: 1 2

Clarifying socket binding strategies - daddyd - 07-21-2014

Actually, ever since you performed your magic on my system my Isy has been working without issue. It should be noted however, I am still on 4.5.4.

Clarifying socket binding strategies - Dean Roddey - 07-21-2014

OH, ok, that's why. It was only a problem once you got to 4.5.5.

Clarifying socket binding strategies - Dean Roddey - 07-22-2014

I updated the first post to include a BindRemote() method. Apparently in some cases the target requires you to be bound to a specific local address, not the ANY address. The ISY's UPnP style discovery code turned out to be one of these. It wouldn't work unless explicitly bound, so I added BindRemote() to deal with these issues.

If you know your target address, BindRemote() will insure you get bound to the correct local address to talk to the remote address. It does assume that you are talking to a single target. If you use more than one, then to insure it will work you would have to create a new socket each time and bind remote again. The new target might not be reachable from the same local interface. But, I would think that in most any situation where you really need BindRemote() you will only be talking to a single target.

This change will be in 4.5.7, and I think we will have all of the weapons we need to deal with the binding stuff. Most of the time the answer is just say no. But, when not, the tools are there to safely deal with it.

Clarifying socket binding strategies - rbroders - 08-08-2014

Just upgraded to 4.5.8 and my ALC Lighting Driver won't compile. It was originally written by BeelzeRob and included both IP access and Serial access. I do not use or understand the IP code, which is now failing to compile.

If (m_UseIP)
//              If (!m_Socket.GetIsBound())
//                    m_Socket.DefBindLocal(SockProtos.TCP);
//              EndIf;
                    m_Socket.Connect(SockProtos.TCP, m_DeviceIP);
                    Return True;
                    // Don't need to close here, just eat the exception

                Return False;

Am I correct to simply remove the first three lines of code?

Clarifying socket binding strategies - Dean Roddey - 08-08-2014

Yeh, that should be fine.