VERY strange side effect (sockets and window messages) !

[Stoodent]

Hi,
I noticed a very strange behaviour in my win32 mdi application which I cannot explain at all. Maybe there is someone who can imagine ?

Ok, I have an application which starts two other processes using CreatProcess(). The other processes shall open a tcp connection on a given port (those processes are corba services: naming service and interface repository).
Since it may be that it takes some time for them to open their ports I wrote a method which checks if it has been opened or not (using GetTcpTable() of Iphlpapi). This method is called inside a loop, so it checks for the ports to be opened until: either all ports are opened OR timeout condition is fulfilled.

I set the timeout condition to INFINIT and noticed that if I start my program the first time after reboot the ports will never be opened UNTIL I move any window on the desktop ?!???!!!!??????

Ok, I placed a "AfxGetMainWnd()->SendMessage(WM_MOVE);" inside the loop and voilá now it seems that the ports open imediately.

WHAT IS THAT ?

May it be that to processes which I expect to open those ports use something which wants me to send such window messages ?
Or do winsockets have anything in common with window messages ???

Thank you in advance if anybody of you could ever give me any hint.
I'm confused.

[ahoodin]

Please supply the following:

OS version
Compiler and version
other helpful info too:
(MFC Sockets, CSockets etc...blocking etc)

ahoodin

[Stoodent]

OS:
Microsoft Windows 2000, SP 4

Compiler:
Microsoft Visual Studio 6.0 (c++), SP 6

Sockets:
Don't know.
Actually I haven't implemented the communication mechanism myself but I used ProcessExplorer by SysInternals which enables you to see which ports have been opened by an application (you can also use command line 'NetStat') and there I could see that the port is just opened after a window message has been sent. So my question was what have win sockets to do with window messages ?

[ahoodin]

What kind of sockets?

It makes a difference. This sounds like a variation of silly window syndrome.

ahoodin

[ahoodin]

Well you did not answer all my questions.

You probably need to read a book.

Here is some helpful info:

Heuristic 7: Do not block inside a user interface thread.

This heuristic sounds more like a straightforward rule of Windows programming, but I bring it up because most programs are single-threaded. In a single-threaded GUI program, any time you call a Winsock function that blocks the UI thread, buttons can't be pressed, menus won't pull down, scroll bars won't move, keypresses are ignored...your UI freezes.

You still did not answer all of my questions...what flavor of socket?
Are you using a CSocket object? Are you using standard 'C' sockets with a socket descriptor akin to a file descriptor?

ahoodin

[Stoodent]

The method which is waiting for the tcp ports to open runs in another thread (worker thread). The GUI is able to interact with the user while the other thread is waiting for the tcp ports to open which is done by the processes startet before by CreateProcess() in the same thread which has the mothod which waits for them to open.

Actually there are 4 threads:

1. GUI thread of my app
2. Worker thread of my app
3. Main thread of process my app created.
4. Main thread of other process my app created.

[Stoodent]

To answer the question about which kind of sockets are used I need to look inside the corba sources (the library I use) because I didn't implement the mechanism myself.
But that library is huge and maybe you have an idea what may ever interfere sockets, tcp thinggies ... (I actually don't know much about that) and window messages.

By the way (if anybody is interested) MICO is used as corba component.

[ahoodin]

In all honesty, I suggest dumping that and learning sockets.

The extra effort will be worth the wait.

Heres a good website to learn sockets:
http://tangentsoft.net/wskfaq/glossary.html

How can you debug what you will not understand?

ahoodin

[MikeAThon]

AFAIK, there's no interaction between Windows messages and the winsock functionality, so it should be possible for winsock to open sockets before any Windows messages (like WM_MOVE) are sent.

There must be something else going on.

Try an experiment. You state that there are four threads that you are focussing on:

1. GUI thread of main app
2. Worker thread of main app
3. Main thread of first process main app created.
4. Main thread of second process main app created.

The first and second processes are the CORBA processes that you don't understand fully.

In the experiment, try substituting stub applications for the first and second processes; the stubs should simply create sockets and bind them to ports. Maybe call listen() too. Then let us know if you see the same behavior.

Incidentally, please also let us know why it's necessary for your app to run so early after a re-boot, that the user has still not even moved a window. Is it a service?

Mike

[Marc G]

[ moved thread ]

[Stoodent]

In all honesty, I suggest dumping that and learning sockets.
The extra effort will be worth the wait.
...

I guess you're right. I just had the hope that there could be any quick hint which makes me look for a specific issue in order to spot the error.
Thank you for your help.

AFAIK, there's no interaction between Windows messages and the winsock functionality, so it should be possible for winsock to open sockets before any Windows messages (like WM_MOVE) are sent.

I found out that moving the window of the application makes the other applications (other processes, other threads) open their tcp ports.
Just sending WM_MOVE seems to be not enough, as I found out today.

...
Try an experiment. You state that there are four threads that you are focussing on:

1. GUI thread of main app
2. Worker thread of main app
3. Main thread of first process main app created.
4. Main thread of second process main app created.

The first and second processes are the CORBA processes that you don't understand fully.

No, these are threads, not processes.
1. and 2. are threads of my app - 3., 4. are threads of the corba services.
In thread #2 there is a method which calls CreateProcess() to start the corba services (threads# 3., 4.)

...
Incidentally, please also let us know why it's necessary for your app to run so early after a re-boot, that the user has still not even moved a window. Is it a service?

No it is a Win32 MDI application consisting of at least two threads. It does not run as a service.
The user may move windows. It just helps to make the corba services to open their tcp ports only if the user moves any window AFTER the processes are created:
Example scenario:
1. User pushed a button. (message handler in thread #1 processes message and starts thread #2)
2. In thread#2 corba processes (called corba services, but these are just normal processes) are startet.
3. In thread#2 runs a loop wainting for both processes to open their tcp connection
4. NOW the user must move any window (e.g notepad or any other window)
5. TCP ports get open and method in thread#2 can communicate with those other procs.

Thank you guys, for your help.
I appreciate it.

[ahoodin]

Stoodent, if you feel we helped you, dont forget to rate. Thats what the rating system is for.

Thanks,

ahoodin

[MikeAThon]

I found out that moving the window of the application makes the other applications (other processes, other threads) open their tcp ports. Just sending WM_MOVE seems to be not enough, as I found out today.

There's a very old MFC problem with CSocket class, where if the app did not receive messages, then the socket connection would freeze or become slow. It's described here: "FIX: Sockets Application Hangs or Exhibits Poor Performance" at http://support.microsoft.com/default...b;en-us;155177

This was fixed as of MFC ver 4.2 (i.e., around 1998), but if the Corba applications are older and use MFC's CSocket class, then that might explain what you're seeing. To determine if this might be a cause of the problem, try just moving the mouse around all over the screen, rather than moving a window.

Did you try the experiment that I suggested? It's fairly easy to code, and it will tell you immediately if the problem lies with your code or with the Corba applications.

No, these are threads, not processes.

I don't understand why you say "no", since I virtually copied your own description of the threads from seven posts above this one. If you give inaccurate descriptions, it's very hard to help you.

Best,
Mike