EldoS | Feel safer!

Software components for data protection, secure storage and transfer

TCP transport hanging on Windows 2000

Also by EldoS: CallbackFilter
A component to monitor and control disk activity, track file and directory operations (create, read, write, rename etc.), alter file data, encrypt files, create virtual files.
Posted: 10/25/2006 08:51:23
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Fantastic! I am really looking forward to this!

I really like MsgConnect and this may just fix any issues that I have with it right now!!!

Thank you.
Posted: 10/25/2006 13:58:38
by Eugene Mayevski (EldoS Corp.)

New build is available for download. Announcements will follow tomorrow.

Sincerely yours
Eugene Mayevski
Posted: 10/25/2006 18:41:14
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Hello my good friend, Eugene.

I have implemented and tested your "new build" and it fixes the UDP open port artifacts -- thank you for that! That is to say that all TCP and UDP connections are dropped when the appropriate transport is made inactive (Active := False).

1. However, my application can still hang on Win2K (not every single time, but often enough that it is a significant problem). The hang appears to happen within the "Active := False;" transport property assignment and I do not seem to be able to reproduce this error in the very simple demonstration program that I have posted. Perhaps it is related to message handlers or something like that?

Note: I tried to work around this problem by freeing (destroying) the TdmRsiComm object (actually, it is a class that has this as a base-class) and then instantiating another instance, but that did not work either. My demonstration program also shows how I create the TdmRsiComm object...

2. Still do not get an OnDisconnected event. I have updated my demonstration client-server application to demonstrate this issue to you. Steps to reproduce the issue:

1. Start Server application.
2. Start Client application.
3. Click on the client's "Test" button.
4. Click on the client's "Signoff" button.

Expect to see the server produce a MessageBox with the caption "Stub" and the text "OnDisconnected", but I do not. What do I need to do to get this MessageBox to appear within the OnDisconnected event?

Currently, I spawn a thread every 90 seconds to check for connections that my server has not heard from in the last 90 seconds. This approach requires more CPU cycles and it takes much longer for the server to realize that the client has gone away.

Once again, thank you for your very kind assistance in resolving these issues.

[ Download ]
Posted: 10/27/2006 03:26:21
by Eugene Mayevski (EldoS Corp.)

The solution for the second problem is quite simple:

implement a handler for OnConnected and allow the connection. I will introduce the necessary changes for the next build.

Regarding the first problem: yes, the problem can be related to message handlers. Or it can be related to synchronization between SendMessage code and the worker threads. What you can do is:
1) change SendMessage to SendMessageTimeoutCallback or to SendMessageTimeout. If it's SendMessage that blocks execution, than use of the mentioned functions will let the waiting stop at some moment. And if the application unblocks after some waiting, this would mean that really the SendMessage was the reason.
2) Is it the client or server that hangs?

Sincerely yours
Eugene Mayevski
Posted: 10/27/2006 14:03:16
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Hello my friend,

Thank you for your kind assistance.

1. Implementing the OnConnected event did cause the OnDisconnected event to be invoked! Thank you for helping me with this.
2. MaxTimeout appears to do nothing (“Defines how long to wait for some signal from the remote side during message transfer.”), and this makes the TMCSocketTransport more complicated than it need be, because the MaxTimeout property is ignored and the InactivityTime provides the same functionality and actually works (“Specifies how long the inactive connection is kept.”). I recommend that you remove the redundant InactivityTime property and ensure that the MaxTimeout property works as expected.
3. Although I have not pinpointed the “client” hanging problem (using a stmP2P TransportMode), when the Transport is made inactive (Active = False), it will hang with some degree of frequency under Win2K. Right now, I suspect that this is due to an invalid memory reference, because of some strange things that have happened in my Delphi IDE while experimenting with my very simple demonstration programs. I do not think that any SendMessage transactions are occurring at this point, although there probably is a whole bunch of UDP messages being received.

Posted: 10/27/2006 14:30:22
by Eugene Mayevski (EldoS Corp.)

MaxTimeout and InactivityTime are *completely* different things, which don't depend on each other.

InactivityTime controls the time, how long the TCP connection is kept when there are no messages being sent or received.

MaxTimeout is used by MMFTransport at the moment. But it's introduced in BaseTransport and can be used by other transports (i.e. if somebody develops one).

Sincerely yours
Eugene Mayevski
Posted: 10/27/2006 15:34:54
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Hello my friend,

Although the MaxTimeout and InactivityTime may be *completely* different things -- that is not clear in the documentation and the documentation would indicate otherwise.

In my opinion, the MaxTimeout should have been implemented in the TCP Transport... and it actually was (by definition) in the InactivityTime ("Defines how long to wait for some signal from the remote side during message transfer." Vs “Specifies how long the inactive connection is kept.”).

As we are encountering issues with MsgConnect, having properties that do nothing (i.e.: MaxTimeout), does not make my testing and software development any easier.

Please do not take my statements as being an argument, as I really like MsgConnect. It is my hope that we can resolve the issues I have encountered and generally make the product better through end-user feedback.

I now get an OnDisconnected event, providing I also define an OnConnected event. However, we have yet to resolve the original issue of the TCP transport hanging on Win2K…

I try using SendMessageTimeoutCallback or SendMessageTimeout method calls, instead of the SendMessage call, so see if it will resolve the issue – but I must admit that I do not believe that it will, since no messages are being sent (that I know of), when the Transports are deactivated (Active := False;).

Once again, thank you for your very kind assistance!
Posted: 10/28/2006 00:51:05
by Eugene Mayevski (EldoS Corp.)

Christopher Zielinski wrote:
In my opinion, the MaxTimeout should have been implemented in the TCP Transport... and it actually was (by definition) in the InactivityTime ("Defines how long to wait for some signal from the remote side during message transfer." Vs “Specifies how long the inactive connection is kept.”).

The descriptions are precise. And they are *different*. First *waits* for signal during message transfer. Second controls socket inactivity. Whenever the properties have different meaning, they are different. It's very bad design to use one property for several different actions. And it's good to have many properties which allow precise control over execution.

Sincerely yours
Eugene Mayevski
Posted: 10/28/2006 10:49:52
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Hi my friend,

I do not want to divert attention away from the hanging issue with an argument over something that is somewhat unimportant (to me).

Perhaps you could update the MsgConnect documentation (to state that the MaxTimeout property for the TMCUDPTransport and TMCSocketTransport are ignored) or better still, remove this MaxTimeout property from the Delphi Object Inspector for the TMCUDPTransport and TMCSocketTransport components? It is not intuitive to a component user that setting such a property does nothing ESPECIALLY when this value is actually controlled by the associated TMCMessenger MaxTimeout value!!!

Now that I understand how this works, I have nothing to benefit from any argument regarding it. What I was trying to do, is share with you the problems I have encountered so your other costumers will not have to go through the same thing.

For example, I identified:

- Orphaned UDP socket allocations (you have subsequently fixed this)
- A need to have an OnConnected event handler defined in order to have the OnDisconnected event work
- A zero (0) value for the InetTransport.ConnectionTimeout causes TCP hanging because the underlying Windows TCP stack decides to never timeout.

And yesterday, I discovered that setting the Messenger.MaxTimeout value to zero causes all messages sent to the TMCSocketTransport to immediately timeout! A zero value is interpreted as never timeout everywhere else, but for the Messenger.MaxTimeout value it must be the max value (0xFFFFFFFF). Why would anyone want the Messenger to immediately cancel and mark a message as failed? Yes, I understand how you used this value, but you could have done something like this:

function TMCMessenger.SendMessage(Destination: string; var Message:
  TMCMessage; Credentials: PMCMessageCredentials): Integer;
  if not SendMessageTimeout(Destination, Message, [B]MaxTimeout[/B], false, Credentials, Result) then
    raise EMCError.CreateCode(MCError_TransportTimeout);

Where the MaxTimeout property returns a value of 0xFFFFFFFF when it has been set to zero, or better still, the SendMessageTimeout does not timeout with a MaxTimeout parameter of zero

Again, implementing these types of changes will be of no benefit to me! I have already figured this stuff out…

As I have always said... I really like MsgConnect! And, I should benefit every time it is improved!!!
Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages



Topic viewed 17898 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!