ATL / WTL / STL

Re: End a socket listen() operation

3-Jun-14 8:26

Widows 7, Visual Studio 2008, C++, socket operations

My app posts a listen using a socket set to non-blocking. The debugger steps over that line, with a noticeable pause, and continues. The netstat command showed that a listen was in progress.

I can think of a few possibilities to end the listen().

1. Client connects
2. Call some method to terminate the listen.
3. Delete the object that initiated the listen

If the client does not connect, how should the app close the listen() operation?

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

Albert Holguin5-Jun-14 9:41

Albert Holguin

5-Jun-14 9:41

Typically in Windows just closing the socket causes the listen to terminate.

Re: End a socket listen() operation

bkelly1313-Jun-14 4:17

detect event in MFC dialog

13-Jun-14 4:17

I will do it that way. Thank you.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

bkelly1331-May-14 11:51

31-May-14 11:51

Windows 7, Visual Studio 2008, MFC, C++

A thread is started when a dialog button is clicked. The thread performs some tasks than sets event 100, an arbitrary number for conversation. The dialog is to detect that event and display some text without user intervention. What can be done in the dialog to accomplish this?

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

Richard MacCutchan31-May-14 21:00

31-May-14 21:00

It would be a better idea to use the proper Windows mechanisms. When the thread has completed its task it should send a message to the dialog.

bkelly131-Jun-14 1:06

1-Jun-14 1:06

Valid point. But this thread is will operate in an environment with no window and will set several events multiple times before exiting. No messages, only events. MFC and the dialog are being used as a test vehicle to get close to the thread during development.
Maybe I should switch to a console environment now. Or continue on a use a button to poll for events then update the status as appropriate.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

Richard MacCutchan1-Jun-14 1:15

1-Jun-14 1:15

bkelly13 wrote:
an environment with no window and will set several events

Without knowing how and where it sets these events it's difficult to suggest anything else. However, you may like to look into the various IPC mechanisms[^].

Randor 1-Jun-14 19:08

Randor

1-Jun-14 19:08

Hi,

bkelly13 wrote:
Valid point. But this thread is will operate in an environment with no window and will set several events multiple times before exiting. No messages, only events.

Threads can have a messages queue on Microsoft Windows. How to post a thread message to a console application.[^]

Using PostThreadMessage function[^] would be a great way to solve your issue. Potentially without creating additional threads.

Best Wishes,
-David Delaune

Kamery do monitoringu - telewizja przemysłowa

monitsystem2-Jun-14 6:44

monitsystem

2-Jun-14 6:44

bkelly132-Jun-14 9:13

2-Jun-14 9:13

That looks useful. My TCP app can post messages to a dialog so the user can determine the state of the thread. One dialog might display the status of several instances of the message app. I will have to figure out how the app will get the ID to that dialog, but it may well be useful.
Thank you for the tip.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

Albert Holguin5-Jun-14 9:49

Albert Holguin

5-Jun-14 9:49

Messaging is likely the best alternative (although not the only option). It is also common for people to make invisible windows simply for the messaging mechanism (instead of handling it by hand as in the article below).

Your other alternative could be to have the window occasionally check a critical section (or mutex) protected variable to know the current state.

modified 6-Jun-14 12:42pm.

bkelly135-Jun-14 14:56

5-Jun-14 14:56

This MFC dialog is just a test vehicle to develop the classes and thread that will perform all the TCP/IP I/O. I will add a button to poll the events set by the TCP code, or maybe a button that starts a timer that leads to a poll every couple of seconds.
Thanks for taking the time to reply.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

check if dll is registred as x32 or loaded to Out_of_process

Albert Holguin6-Jun-14 6:44

Albert Holguin

6-Jun-14 6:44

I use the polling method for high-frequency updates to a GUI. Since messaging can lead to a flood of messages updating things at such a high-rate you probably wouldn't make out the least significant digits.

MrKBA25-May-14 12:37

MrKBA

25-May-14 12:37

I have a win32 COM which is developped to work as win32 and it can be registred to run as surrogate dll with client application x64.

1) Before modification of it to be called into out_of_procces,this dll use Microssoft.Jet.oledb.4 to connect and create mdb files.and this was working fine.
2) after the modification to let this dll be loadded by x64 application as surrogate and changing the Microsoft.Jet.oledb by Microsoft.ACE

This dll not work now when version of office is x64.
And this is normal because it is x32

Questions:
- can i check at run time if the dll is registred as x32 or x64 ?
- if yes can i define the driver of office related to the version of dll at run time
Ie:
If registred as 32 then use Microsoft.Jet.oledb
Else if dll surrogate (x64) then use Microsoft.ACE

Thank you

Re: check if dll is registred as x32 or loaded to Out_of_process

Randor 1-Jun-14 19:01

Randor

1-Jun-14 19:01

Hi,

Think outside the box. By calling the IsWow64Process function[^] you can detect whether or not you are loaded into a 32 or 64 bit process and act accordingly.

Best Wishes,
-David Delaune

assign an event to a socket operation

Member 798013518-May-14 15:57

Member 7980135

18-May-14 15:57

Windows 7, Visual Studio 2012, winsock

Edit: Oops, posted in ATL rather than C++. If you are an admin type, please move it.

How is an event associated with a socket operation? For example:
[code]

// start listening for new clients attempting to connect
    iResult = listen(ListenSocket, 1);

[/code]
The socket is non-blocking and the code continues while waiting for the listen operation to complete. I want event: CLIENT_DETECTED (arbitrary name, I know how to create the event.) to be triggered when a client solicits a connection. Yes, I understand a bunch of code is needed to capture that event and do something.

Thank you for your time.

modified 18-May-14 22:06pm.

Richard MacCutchan18-May-14 21:28

18-May-14 21:28

See http://msdn.microsoft.com/en-gb/library/windows/desktop/ms739168(v=vs.85).aspx[^], listen is a blocking call.

bkelly1319-May-14 13:07

19-May-14 13:07

Hello,
OK, its there as in:

Quote:
Note When issuing a blocking Winsock call such as listen, Winsock may need to wait for a network event before the call can complete.

I presumed that it could also be non-blocking. Then they carry on with:

Quote:
Winsock performs an alertable wait in this situation, which can be interrupted by an asynchronous procedure call (APC) scheduled on the same thread.

So in order to kill the program when no client comes a-calling, I need to learn this. I will search but if you have a link to a good article on this, that would be appreciated.

Thank you for your time.

Edit: While re-reading the MSDN page on listen(), I noticed that the words are:

Quote:
... Winsock may need to wait for a network event....

Directing attention to the word "may," that means that there are circumstances in which Winsock does not need to wait for a network event. Should that statement have stated that Winsock "will" wait for a network event? Or is there another way out of the Listen call?

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

modified 19-May-14 19:46pm.

Richard MacCutchan19-May-14 21:34

19-May-14 21:34

bkelly13 wrote:
Should that statement have stated ...

I cannot answer for Microsoft's wording. My reading of it is that listen always blocks for a connection to complete, it should not be too difficult to test.

bkelly1320-May-14 6:20

Listen can be non-blocking

20-May-14 6:20

I am going with that.
Thank you for taking the time to reply.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

bkelly133-Jun-14 8:19

my icon in system tray always visible

3-Jun-14 8:19

I have finally progressed to the point of testing the listen() function. This app sets non-blocking attribute and the code steps right over the listen() call, with a noticeable pause.

Now the question becomes: Is there a proper method of stopping a listen in progress? There are WSASend() and other socket methods with additional arguments, but I did not find a WSAListen(); I will post that as a new question.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

Member 104023906-May-14 8:16

Member 10402390

6-May-14 8:16

How implement "my icon in system tray always visible"?

thanks.

Re: my icon in system tray always visible

Richard MacCutchan6-May-14 9:07