EldoS | Feel safer!

Software components for data protection, secure storage and transfer

One Issue Fixed, Another Issue Introduced

Also by EldoS: SecureBlackbox
200+ components and classes for digital security, signing, encryption and secure networking.
#2033
Posted: 01/23/2007 10:39:47
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Hello,

Previously we encountered software hanging when we closed MsgConnect communications (prior to version v.1.5.7.50 -- I have not tested/used v.1.5.7.50 or v.1.5.7.51). We just upgraded to v.1.5.7.52 and are very happy to see that this hanging appears to be fixed (possibly because of the information I previously provided regarding it).

However, we now have a new issue. Our MsgConnect UDP broadcasting / multi-casting communications no longer work, unless both ends of the communictions are running on the same machine.

Do you have any suggestions on how we may get our MsgConnect UDP broadcasting (255.255.255.255) or multi-casting (e.g. 224.0.39.255) working again, across the network?

Look forward to your kind and prompt reply...
#2034
Posted: 01/23/2007 10:57:22
by Eugene Mayevski (EldoS Corp.)

Nothing was changed in UDP for ages. Maybe it's some configuration issue (such as certain winsock 2 constants being overwritten by winsock 1 declarations). We will check this asap.


Sincerely yours
Eugene Mayevski
#2035
Posted: 01/23/2007 11:47:22
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Quote
Eugene Mayevski wrote:
Nothing was changed in UDP for ages. Maybe it's some configuration issue (such as certain winsock 2 constants being overwritten by winsock 1 declarations). We will check this asap.


You are truly wonderful. Thank you for your prompt attention to this matter. If this issue is resolved without introducing any other issues... I think MsgConnect will work perfectly in our software solution that uses it!!!
#2038
Posted: 01/24/2007 09:52:22
by Eugene Mayevski (EldoS Corp.)

A quick test didn't reveal any problems with UDP broadcast or multicast. Both of them work. Not in all configurations though - I've tested communications between multihomed system and a VMWare system, so VMWare router also played his role. But in general, the stuff works ok.


Sincerely yours
Eugene Mayevski
#2039
Posted: 01/24/2007 10:22:21
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Quote
Eugene Mayevski wrote:
A quick test didn't reveal any problems with UDP broadcast or multicast. Both of them work. Not in all configurations though - I've tested communications between multihomed system and a VMWare system, so VMWare router also played his role. But in general, the stuff works ok.


Well, our test environment is all Windows-based. What used to work, no longer works, with regard to UDP multi-casting (using both the general broadcast address of 255.255.255.255 and the multi-cast address of 224.0.39.255).

The only thing that has changed, is the version of MsgConnect that we use.

I guess we will continue to use your latest version, as it has fixed so many issues!

As for the multi-cast, perhaps we will replace it with Indy components or change it from multi-cast to direct UDP messaging to each endpoint (assuming that direct UDP MsgConnect messaging is not broken as well -- as we have not tested this approach yet).

Hope you continue to investigate this issue futher, as we have always had this dance over the last two years where I report a problem, you suggest that it does not exist, and then many months later you actually find and fix the issue. Just look back at your MsgConnect change history and the issues that I have reported in the past.

#2040
Posted: 01/24/2007 10:50:49
by Eugene Mayevski (EldoS Corp.)

OK, if you don't believe ... CVS contains revisions 1.46 (this one was created in June, 2006) and 1.47 created in October. The only difference between them was implementation of TUDPSocket.Destroy destructor.

You can comment out this destructor (this will lead to UDP socket leakage) and see if this changes anything.

There was also one addition made to the recipient socket. To "discard" this edition set UDPTransport.ReuseServerPort property to false.

These are the only 2 changes within the last 2 years.


Sincerely yours
Eugene Mayevski
#2042
Posted: 01/24/2007 11:24:10
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Well, my friend... I remembering going through all this under the topic "TCP transport hanging on Windows 2000", and that issue has been fixed in the latest release v.1.5.7.52.

If not mistaken, has been fixed by your companies UDP destructor fix.

Unfortunately, I have confirmed the following from our tester:

  • Server computer has a single network card
  • Client computer has single network card
  • Previous build of our software worked in this environment
  • Current build of our software does not work in this environment (due to UDP communications failure)
  • All that has changed between the testing of our two builds is the version of MsgConnect


Do I have access to CSV? It does not matter, because going through previous builds of MsgConnect is unlikely going to fix my current issue.

Now that I know that a fix is unlikely to come from your company, I will investigate other means of currecting the issue. After all, I must fix the issue and your company's latest release fixes the hanging issue we previously reported.

Regardless, thank you for looking into this and suggesting how I should proceed in fixing the issue.
#2043
Posted: 01/24/2007 11:36:52
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Quote
Eugene Mayevski wrote:
OK, if you don't believe ... CVS contains revisions 1.46 (this one was created in June, 2006) and 1.47 created in October. The only difference between them was implementation of TUDPSocket.Destroy destructor.


BTW: You did mean the only diferences between versions v.1.5.7.49 and v.1.5.7.52 -- correct?

Having read the comments in the MsgConnect changes.txt file... another (very minor) change I made to the build was to turn off compiler optimization in the projects options.

I will also try simply recompiling the project, as the project may not have been built correctly by the compiler (although such a problem is unlikely, since I always recompile everything for a production build).

If I should discover anything on my end... I will certainly post that information here... as I would not want to post any false information about your product.

If we can get multi-casting/broadcasting working again, without breaking anything... MsgConnect will be the PERFECT solution for our needs, and I still have not given up on finding a work-around (like changing multi-cast communications to a much higher band-width intensive endpoint-to-endpoint UDP messaging system).
#2044
Posted: 01/24/2007 11:51:13
by Eugene Mayevski (EldoS Corp.)

Quote
Christopher Zielinski wrote:
Well, my friend... I remembering going through all this under the topic "TCP transport hanging on Windows 2000", and that issue has been fixed in the latest release v.1.5.7.52.

If not mistaken, has been fixed by your companies UDP destructor fix.


This was not a fix of your problem. It was a fix of a socket handle leak. The socket handles are closed when the application is shut down anyway. If your network driver hung when closing those socket handles, this is another story.

Quote
Christopher Zielinski wrote:
Do I have access to CSV? It does not matter, because going through previous builds of MsgConnect is unlikely going to fix my current issue.


I've listed both changes that were made during last two years. Reverthing them back brings you to the old version which worked. Please try to do what I described and let me know if this solves the problem.


Sincerely yours
Eugene Mayevski
#2048
Posted: 01/24/2007 23:33:32
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Quote
Eugene Mayevski wrote:
This was not a fix of your problem. It was a fix of a socket handle leak. The socket handles are closed when the application is shut down anyway. If your network driver hung when closing those socket handles, this is another story.


I have got to close this issue. Previously I was using information that was provided by our quality assurance department. Unlike any of the other issues that I have reported, I did not personally verify this prior to submitting it to your attention.

It took MsgConnect developers serveral months to fix the hanging problem I had reported -- which if my memory is correct, was due to the transport system getting confused because the disposition of previously opened sockets did not occur (correctly). Or at least, we do not have this problem now that you have fixed your socket leak.

What I am saying, is that I apologize for having submitted an issue that I personally did not verify. Normally I would not have done this, but I got careless because of our previous history.


To all those that read this... I really like the MsgConnect architecture, and believe that it is a very stable and mature product now, although you would have to evalute its appropriate use in light of your own requirements.
Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.

Reply

Statistics

Topic viewed 12258 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!