Hello,

My question is the same as the subject:

How to perform a non-blocking synchronous ReadFile call/operation with
NDISPROT ?

According to Microsoft's documentation ReadFile can be used for synchronous
and asynchronous operation.

However the ReadFile documentation doesn't really mention how to perform the
synchronous operation.

It also doesn't really mention that ReadFile is initially blocking ? Because
during testing it seems to block.

If it is in the documentation for ReadFile than I surely missed it.

The only thing which hints at synchronous operation is the
link/mention/reference to the COMMTIMEOUTS documentation.

This is probably more of a general windows programming topic. But still who
knows what quarks NDISPROT might have

How are synchronous operation with ReadFile done generally ?

Am I supposed to set a timeout ?

Is that the way to go ?

If so... will NDISPROT return partial packets because of a timeout or will
it buffer packets and only return full/whole packets/frames ?

I don't want to use asynchronous calls for now because that interrupts the
code flow. I simply want my code to move on and not have to deal with
callbacks, event handlers etc.

Is there any other method to prevent the blocking in a simple way...

Maybe using select() ? Or something like that ? Because select() is probably
only a winsock function ?

Select also works with a timeout if I am not mistaken so the first method is
probably more or less the same idea.

Bye,
Skybuck.

AFAIK the read will not complete until there is something to read. That's
the driver behavior. If you want a different behavior, then you will have to
modify the driver to suit your desires.

OTOH, your best bet is to start a thread that continuously performs reads
and queues the received packets (possibly throwing away unwanted ones). You
can examine the queued packets without blocking. Either there are some to
lookat - or there aren't.

The behavior is much like reading from a file (either synchronously or
asynchronously). If you make a ReadFile call, it won't complete until you've
read something.

Thomas F. Divine, Windows DDK MVP



"Skybuck Flying" <spam@hotmail.com> wrote in message
news:447248ec$0$713$5fc3050@dreader2.news.tiscali. nl...

Also, use the MSDN. A search for "ReadFile synchronous" brings up 500 topics
(too broad a search...), BUT the first three in the list seem to answer your
question about how to perform synchronous/asynchronous I/O.

Thomas F. Divine, Windows DDK MVP
http://www.rawether.net

"Thomas F. Divine [DDK MVP]" <tdivine@NOpcausaSPAM.com> wrote in message
news:O1KK%23JgfGHA.3996@TK2MSFTNGP04.phx.gbl...

Yes most of the links provide lot's of information about synchronous and
asynchronous I/O.

However there is no mention of "non blocking" synchronous I/O.

The only thing which seems to be about "non blocking" synchronous I/O are
these lines of text:

"
When reading from a communications device, the behavior of ReadFile is
governed by the current communication time-out as set and retrieved by using
the SetCommTimeouts and GetCommTimeouts functions. Unpredictable results can
occur if you fail to set the time-out values. For more information about
communication time-outs, see COMMTIMEOUTS.
"

Bye,
Skybuck.

"Thomas F. Divine [DDK MVP]" <tdivine@NOpcausaSPAM.com> wrote in message
news:ejj2CYgfGHA.4464@TK2MSFTNGP04.phx.gbl...

"Thomas F. Divine [DDK MVP]" <tdivine@NOpcausaSPAM.com> wrote in message
news:O1KK%23JgfGHA.3996@TK2MSFTNGP04.phx.gbl...
Maybe this is not true.

Microsoft mentions the following lines of text:

"
ReadIntervalTimeout
Maximum time allowed to elapse between the arrival of two bytes on the
communications line, in milliseconds. During a ReadFile operation, the time
period begins when the first byte is received. If the interval between the
arrival of any two bytes exceeds this amount, the ReadFile operation is
completed and any buffered data is returned. A value of zero indicates that
interval time-outs are not used.
A value of MAXDWORD, combined with zero values for both the
ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies
that the read operation is to return immediately with the bytes that have
already been received, even if no bytes have been received.
"

Text is from this link:

http://msdn.microsoft.com/library/de...meouts_str.asp

This is were my confusion starts.

At first it would seem you are correct.

The first lines of text start with:

"... the time period begins when the first byte is received."

So this would mean the timer starts only when something is received.

Now my confusion starts with what seems to be an exception to this rule ?

"
A value of MAXDWORD, combined with zero values for both the
ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies
that the read operation is to return immediately with the bytes that have
already been received, even if no bytes have been received.
"

So this seems to be an exception to the general rule.

To me it seems ReadFile can return even if nothing was received.

Have you ever tested this ?

Bye,
Skybuck.

Are you reading about a COM port?

NDISPROT is not a COM port...

Thomas F. Divine

"Skybuck Flying" <spam@hotmail.com> wrote in message
news:44726705$0$745$5fc3050@dreader2.news.tiscali. nl...

The documentation does not mention a COM port specifically.

It just mentions a communication device which could be anything.

Bye,
Skybuck.

"Thomas F. Divine [DDK MVP]" <tdivine@NOpcausaSPAM.com> wrote in message
news:%23SLUsogfGHA.356@TK2MSFTNGP02.phx.gbl...

In practice, this is restricted to serial (COM) ports and anything that
emulates those.

"Skybuck Flying" <spam@hotmail.com> wrote in message
news:44729336$0$746$5fc3050@dreader2.news.tiscali. nl...

I afraid no ways without patching of NDISPROT's code.

In general, Windows does not support non-blocking synchronous IO. Only some
drivers like the sockets (AFD) support it, but there is no general architecture
for this in Windows. No fcntl() analog.

You can add this support to NDISPROT by, for instance, using the
FILE_NO_INTERMEDIATE_BUFFERING for this purpose or such.

Correct, async or fully blocking sync, nothing else. Nonblocking sync (which
fails with EAGAIN but never waits) - is not generally supported across the OS,
but some drivers can support it.

Yes.

Correct. Windows supports select() on sockets only.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Correct, no uniform support for this in Windows, neither is for select().

Correct. Serial port driver supports nonblocking IO to some extent, and sockets
also support it, but I think no other drivers.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Ok,

I tried it anyway to see if it would work

And nope it doesn't work so you guys correct this is only for ComPorts it
seems hehehe.

Bye,
Skybuck

"Skywing" <skywing_NO_SPAM_@valhallalegends.com> wrote in message
news:%23WwmuTifGHA.3588@TK2MSFTNGP02.phx.gbl...