hi all,

i've a little problem (but not so little i think), surfed the web but the most MFC famous articles with author photo and other magic stuffs can't solve it... so i tought that my win32friends surely can :)

Here is the issue:
there is a communication between a central machine and a periferic machine. I'm working on the periferic and i can't change the central (server) application. I have to do a timer in a thred couse i have to send by socket a ping message only if in 4 seconds i don't send anything else.. this to keep alive the connection. If the center don't receive anything in 4 seconds it close down the connection.

So i'm in a communication thread where i receive in continuos fashon, and i need to set a timer of 3 seconds. When it's elapsed i have to send this kind of ping message.

Here is the problem: seems is not possible, under visual C++ (MFC) create a timer from a thread.. with a thread internal Timer callback routine. Or better, is possible only if you have a message pump in the thread that can look for a WM_TIMER message. But i can't seems i already have the communication message pump.

So i really have not idea for other ways to do it...

Probably someone of you have mopre experience and already solved problem like this. If any suggestion, infinite thanks. B7
Posted on 2004-01-22 10:59:17 by Bit7
There's plenty of ways to do it, and the most optimal will depend on your socket strategy, and other things. The way I'm going to describe is probably dumb and brute force, but it should suit most methods.

On every send, note down the current time (don't use GetTickCount as that can wrap around on machines with very long uptimes - or at least "normalize" and use a running delta). It would be a good thing if you write wrappers around send, or even better, if you have some protocol... so you don't have to manually hunt down every send().

Now, either you can create a timer in your main (messagepump) thread, or you can do something else - have your "should I send a ping?" thread Sleep(something) (you can probably get away with 3000 msec, but I'd probably do 250 or something) in a loop. Furthermore, after each Sleep, get the current time, subtract the time of last send. If more than, say, 3000-3500 msec (allowing for relatively slow connection to server) has elapsed since last send, queue a ping for sending.
Posted on 2004-01-22 11:24:25 by f0dder
thanks fodder :), youre great :)


ok, i think the parallel thread Sleep idea could good. since there are not easiest way i will go for that :)
Posted on 2004-01-23 01:38:12 by Bit7
If you don't need greater accuracy than ~25ms (iirc), Sleep is great - especially since your thread isn't scheduled for executing while sleeping. Of course you could handle it with a WM_TIMER in your GUI thread... as long as that thread doesn't block for longer periods of time, and you don't need very high accuracy.

Generally, don't introduce threads if they're not necessary, as there *is* some overhead involved with them (kernel-mode object etc). Scheduler overhead for something like a sleep-ping thread should be neglicable (sp?) though.
Posted on 2004-01-23 01:44:36 by f0dder