Ken
Tue Jun 22 13:51:16 CDT 2004
The thought at this time is to permit the "service support" driver act as a
store-and-forward with a reasonably large amount of space for holding
pending messages. If this pending space becomes full, then we would have a
problem, but by making this large enough and taking steps to ensure the
service is running properly we hope to minimize the impact.
When the service asks for information from the driver, we expect to pass
back all of the currently pending messages (if there are none, then the
request will stall until there is one), rather than always passing one
message at a time. The service will then process these messages as quickly
as possible and then ask for more. As each block of messages is processed by
the service, it would inform the "service support" driver, who would then
remove them from the buffer to make space for more. We are looing into
several methods to achieve this.
If the service were too slow in its processing, then this would create a
severe problem, you are correct, and this would be common to all approaches.
So we must be careful to ensure that the code is efficient and fast enough !
;-)
With the WMI approach, however, we have no mechanism to know when the
consumer has, or even if a consumer ever did, retrieve the message from the
WMI repository. The documentation is a bit scanty, but we came across
several references that have lead us to believe that messages sent to WMI
that are not collected by a consumer within a reasonable amount of time are
simply discarded. The wording in some places was vague, so we are left not
knowing whether the messages are discarded if there is no consumer waiting
for them, or if simply based on time. There is a reference that indicated
that a newly launched consumer might only collect messages from that point
forward, which implied that the messages do not remain in the repository for
very long and that there is no facility for querying historical information.
The specific messages we need to deal with are rather critical, being more
of an audit trail of specific activities, and it is not permitted that some
messages be dropped. If the "service support" driver detects that the pengin
message area is becoming full, then we may be able to put our other drivers
in a read-only state, thus preventing the creation of new messages for a
period of time, but that means the "support driver" must be able to detect
this condition and report it to the initiating drivers. Unfortunately the
size of the messages involved prevents us from using the Event Log kernel
API calls, as these limit us to creating Event Log Entries of no more than
about 150 bytes of data, and some of the messages we need to record are
significantly large than this -- and the Event Log Entries do not provide
the required number of unique 'columns' by which to identify and search the
data. Hence we are considering a service that records into an MSDE or SQL
Server database and a single "service support" driver that collects the
messages from the dynamic number of initiating drivers.
I hope this clarifies things.
-ken
"Peter Wieland [MSFT]" <peterwie@online.microsoft.com> wrote in message
news:OQWTwRHWEHA.2340@TK2MSFTNGP09.phx.gbl...
> how is the "non-determinism" problem you point out with WMI addressed in
> your home-built solution? Are you considering a two-phase commit between
> the driver and the service where the service asks for the outstanding
events
> and then tells you you can clear them once it's written them out
somewhere?
> How are you planning to do flow-control on events when your service gets
> delayed for some reason and can't find processor time or memory to get the
> requests out of the driver queue fast enough?
>
> i'm not trying to criticize your plan, i'm just pointing out that i don't
> think the non-determinisim is only an aspect of WMI.
>
> -p
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Ken Allen" <nospamkendrhyd@sympatico.ca> wrote in message
> news:exRPn%23EWEHA.1356@TK2MSFTNGP09.phx.gbl...
> > Thank you for your responses.
> >
> >
> >
> > In general, what are your feelings toward using WMI to achieve this
> > instead
> > of a custom "service support" driver? I know that the latter would
provide
> > us with more direct control and influence over the actual processing,
and
> > permit us to control the level of 'store and forward' if the service is
> > not
> > running, but the WMI interface already exists.
> >
> >
> >
> > The largest two problems I see with WMI are the pollution of the WMI
space
> > with messages that have nothing to do with WMI, and the
non-deterministic
> > delivery mechanism. Our driver can be certain whether the message was
> > delivered to WMI, but not whether the consumer is active or whether the
> > consumer received the message. If the consumer terminates and is
> > restarted,
> > it seems that messages that arrived in the meantime are likely to be
lost.
> >
> >
> >
> > Could you share your thoughts on this one?
> >
> > -ken
> >
> > "Don Burn" <burn@stopspam.acm.org> wrote in message
> > news:10d3rss70rq23f2@corp.supernews.com...
> >> Replies inline:
> >>
> >> "Ken Allen" <nospamkendrhyd@sympatico.ca> wrote in message
> >> news:%231Fan6JVEHA.1292@TK2MSFTNGP10.phx.gbl...
> >> > Yes, I can see some the merit in what you are proposing here,
although
> >> > I
> >> am
> >> > still trying to work my way through the details (I have written many
> >> device
> >> > drivers for various devices, but mostly for VMS and UNIX, and I am
> >> > quite
> >> new
> >> > to the Windows device driver environment. So forgive me if I do not
> >> > understand some of your specific references.
> >> >
> >> > I have embedded some comments inline below.
> >> >
> >> > Thank for for this reponse and assistance.
> >> >
> >> > -ken
> >> >
> >> > "Don Burn" <burn@stopspam.acm.org> wrote in message
> >> > news:10d3js6icaejpdb@corp.supernews.com...
> >> > > Ok, this does make more sense. Basically, I would create a
"service
> >> > > support driver" that handled the requests, then have the service
> >> interface
> >> > > to it with the common IOCTL "inverted call" model. The "service
> > support
> >> > > driver" would export its services to other drivers in any of the
> > common
> >> > > driver to driver communication models:
> >> > >
> >> > I am presuming that he "inverted call" model is the case where the
> > service
> >> > issues a generic IOCTL to the driver, which does not respond until it
> >> > requires processing from the service, in which case the 'command' is
> > sent
> >> to
> >> > the service in the reponse to the IOCTL; and the response to the
> > 'command'
> >> > is sent to the driver using a new IOCTL. The advantage in this case
is
> >> that
> >> > there would be a single "service support driver" for the service to
> >> > deal
> >> > with, greatly simplifying the user-kernel interface issues.
> >>
> >> Yes the inverted call is as you suspected. The idea here would be to
use
> > a
> >> single driver to simplify the interface.
> >>
> >> > > 1. Device Interfaces - probably the best approach since it
> > allows
> >> > for
> >> > > notification of the "service support driver" loading and unloading.
> >> > >
> >> >
> >> > I presume that this is what you meant by exporting services
(features)
> >> from
> >> > the "service support driver" to the other drivers. Could you clarify,
> >> > or
> >> > direct me to documentation on, "device interfaces"? I am not certain
> > what
> >> > this means specifically, how the "service support drvier" would
differ
> >> from,
> >> > say, a filter driver, how one would configure this, or what the
actual
> >> > drivers would have to do to send the 'packets' to the "service
support
> >> > driver". What about serialization and synchronization of concurrent
> >> packets
> >> > from several drivers?
> >>
> >> See IoRegisterPlugPlayNotification and IoRegisterDeviceInterface.
> >>
> >> > > 2. Kernel mode DLL - simplest model for a "call"
> >> > >
> >> >
> >> > I can see where this makes sense, but I am not sure how to develop
one.
> >> Are
> >> > kernel DLLs shared amoung the various drivers that link to them? So
the
> >> code
> >> > could be used to synchronize/serialize the requests from the various
> >> > drivers?
> >>
> >> Yes, this is a single DLL for all drivers, the basics are identical to
a
> >> driver, the
> >> specifics are covered at
http://www.osronline.com/article.cfm?id=171
> >>
> >> > > 3. IOCTL pointer block - the old reliable works on every
> > version
> >> of
> >> > > Windows back to NT 3.1
> >> > >
> >> >
> >> > Yes, I can see this approach, although it is likely the least
> >> > desirable.
> >>
> >>
> >> --
> >> Don Burn (MVP, Windows DDK)
> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >> Remove StopSpam from the email to reply
> >>
> >>
> >
> >
>
>