Hi,
I have a question about the communication between kernel driver and user applications.
My kernel driver has to communicate with multiple user applications and wait for their replies infinitely to go on.
The requirement is that these communications should NOT influence each other.
For example, even if user application A hangs on and hasn’t reply to kernel driver for pre-create operation of D:\A, user application B can communicate with kernel driver and access D:\B\ normally. (Assume A and B always access different path)
I was thinking create one server port with calling FltCreateCommunicationPort once, and set MaxConnections to the number of applications to communicate.
But I am afraid these communications may be influenced by each other since there’s only one server port.
Then, do I need to call FltCreateCommunicationPort multiple times to create multiple server ports, and bind them to multiple user applications as one server port to one client port?
Ps, the final way I can do to avoid such influence is that to install multiple kernel drivers with each driver only communicate with one application.
Thanks!
On 10/11/2011 1:17 AM, xxxxx@gmail.com wrote:
Hi, I have a question about the communication between kernel driver
and user applications. My kernel driver has to communicate with
multiple user applications and wait for their replies infinitely to
go on. The requirement is that these communications should NOT
influence each other. For example, even if user application A hangs
on and hasn’t reply to kernel driver for pre-create operation of
D:\A, user application B can communicate with kernel driver and
access D:\B\ normally. (Assume A and B always access different path)
I was thinking create one server port with calling
FltCreateCommunicationPort once, and set MaxConnections to the number
of applications to communicate. But I am afraid these communications
may be influenced by each other since there’s only one server port.
Then, do I need to call FltCreateCommunicationPort multiple times to
create multiple server ports, and bind them to multiple user
applications as one server port to one client port?
Ps, the final way I can do to avoid such influence is that to install
multiple kernel drivers with each driver only communicate with one
application.
Thanks!
Each time a client connects to a server port a new client port object is
created. This means that failure of one client won’t prevent Filter
Manager from sending message to other clients.
Message sent from a client to the Filter Manager aren’t put into a
shared queue. Each message generates a device I/O control IRP
(IRP_MJ_DEVICE_CONTROL) that is sent to Filter Manager, so each incoming
message is handled independently.
So, so long as your driver can process multiple channels of
communication in parallel, the Filter Manager communication port
infrastructure shouldn’t preclude you from using a single server port.
–
Christian [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.
Thanks, Christian.
I tried one server port vs multiple client ports, and used connection cookie to distinguish them in Connect/DisconnectNotifyCallback.
So far it works well and these connections run independently.
I guess only if we need different server ports inside a driver (with different Security Descriptor, etc), then we should create multiple server ports. Right?
On 10/12/2011 6:54 PM, xxxxx@gmail.com wrote:
I guess only if we need different server ports inside a driver (with
different Security Descriptor, etc), then we should create multiple
server ports. Right?
Right.
Christian [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.