Vista - How to Make a .NET Timer Always Fire at the Right Time

> That's assuming your protocol actually needs keepalives, as many peopleIt begins to be OT respective with the OP initial demand by may I ask what
you think about the connection being closed after 10 s ? Is this something
usual ?

TIA

--
Patrice

Patrice wrote:I have worked with setups where the server side closed the connection after
just 20 seconds of inactivity, because it was more important for the
connection to be "known good" even at short intervals than it was to be
mindful of the bandwidth wasted this way.

I'm not saying this is a good way of doing things (using short transmission
timeouts is probably a better idea), but I don't think it's unusual either.

--
J.

Charles wrote:No, you can't. Well, to be precise, you can, but there's no thread affinity
for the timer, so you'll just be boosting the priority of some random thread
that's handling the timer callback.

I don't recall if it's possible for the thread that sets the timer to get
the callback if the interval is sufficiently short, but in any case that
won't apply here since your interval is in the range of seconds.
Yes, in principle. There's one caveat with waitable timers, though: they use
APCs to signal completion. This is slightly tricky because the CLR also uses
APCs to communicate with threads (Thread.Interrupt() and Thread.Abort(),
among others, queue an APC on the thread). I recall having some problems
using APCs in managed threads, but nothing specific; it's probably the
general trouble of having to be careful in callbacks from unmanaged code,
especially something as low-level as APCs. I do recall you can use

try {
Thread.Sleep(Timeout.Infinite);
} catch (InterruptedException) {
return; // asked to stop
}

And then call Thread.Interrupt() when your thread should stop.
Thread.Sleep() uses SleepEx() under the covers and will properly respond to
the CLR signaling APCs.

I'd try timer queues first. By default these just use worker threads, so no
mucking around with APCs. They don't allow for boosting priority but they
don't use the .NET thread pool either, so they might be less susceptible to
preemption under load. I have no idea if this is actually the case, but
you'll have to thoroughly test whatever solution you pick anyway, so you
might as well start with the easier ones.

Speaking of which, you really are better off dedicating a machine that's
guaranteed to have low loads to this task, like Mike suggested. :-) If you
can isolate the processes that are ruining it for the rest, you could try
looking into job objects to limit the memory and CPU they're assigned.
Keeping your program simple and not overly reliant on interesting low-level
techniques is certainly worth some effort.

--
J.

* Charles wrote, On 1-11-2009 17:59:Isn't it possible to make that connection more reliable (by leaving it
open longer), or wouldn't it just be possible to switch to UDP instead
and forget the notion of a connection altogether?

Jesse

--
Jesse Houwing
jesse.houwing at sogeti.nl

Hi Jesse

Because it's third-party, I'm at their mercy. This is just the protocol I
have to accommodate.

Charles


"Jesse Houwing" <jesse.houwing@newsgroup> wrote in message
news:#l#KjB0WKHA.3428@newsgroup

If your timer can't respond within, say 5s of the nominated interval, then
surely that indicates that the machine is not responsive, and that is
exactly why the server needs that acknowledgement. If you manage to force
the keepalive even when the machine is bogged down like this, surely you
will risk corrupting the connection because the server is being fooled into
thinking that the connection is active when it isn't.

"Charles" <blank@newsgroup> wrote in message
news:eG3x2DvWKHA.4780@newsgroup

Hi James

Actually, you have a point there. I hadn't thought of it like that. I should
perhaps put more effort into re-establishing the connection when the machine
unfreezes.

On the other side though, the connection is important enough to keep going
at all costs, so if I could make my task higher priority then it would be ok
if other processes suffered slightly.

Charles


"James Hahn" <jhahn@newsgroup> wrote in message
news:uf2SDi1WKHA.3720@newsgroup

It's not really practical to dedicate a machine to this task, and in any
case, if I could assign an appropriate level of priority to the task then
any other tasks would get plenty of time to operate.

The thing that currently seems to upset it is file transfers over RDP. I
occasionally need to copy a file to the machine over RDP, which can take
anything from 1 minute to 30 minutes. There are times in this window when
the machine appears to hang, but I imagine it is just concentrating really
hard on the file transfer. Anyway, that's when my timer goes astray. Giving
a regular 10 second slot to my task would not hinder the file transfer in
any way, and even if it did, I could live with it. It's just a case of
priorities, as it were.

Charles


"Jeroen Mostert" <jmostert@newsgroup> wrote in message
news:4aedf426$0$83239$e4fe514c@newsgroup

Ok thanks I was wondering (as you saw I'm not that familiar with TCP but
thought it was connection oriented and both end had to agree to close the
connection). Charles, sorry for having hijacked this part of your thread ;-)

--
Patrice

Windows is non-deterministic.

As other replies indicate, you simply cannot assure yourself that this
happens -- unless you design you system such that the user (or your own
code) cannot cause trouble. The most reliable way to do this is to dedicate
a processor, another computer, to the time-critical task. It you don't
allow the user, or your own code, to use that environment for anything other
than your time critical process, you should be OK. You'd then add a
non-time critical communications method to that process that communicates
results to your "loaded" machine, where you can then allow the user -- or
your own code -- do things that otherwise mung up the system.

Dick

--
Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
2006.