Hi,
I am learning about NDIS 5 Intermediate Drivers, and i have question 
whats the difference exactly between a N:1 IM Driver and a 1:1 IM Driver?
and what are the advantages\disadvantages between choosing on or the other?
(I.E in what scenarios would you chose one over the other)
Thanks a lot for you time and help
A N:1 IM driver exposes N virtual miniports above each lower-level miniports
that it binds to. Various uses.
A 1:1 IM driver exposes 1 virtual miniports above each lower-level miniports
that it binds to. It is a pass-through filter over the lower-level miniport.
A 1:N IM driver exposes 1 virtual miniport above N lower-level miniports
that it binds to. Perhaps for load balancing or failover.
Thomas F. Divine
http://www.pcasusa.com
From:
Sent: Friday, January 20, 2012 9:38 AM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] NDIS5 IM Driver Question
> Hi,
>
> I am learning about NDIS 5 Intermediate Drivers, and i have question
>
> whats the difference exactly between a N:1 IM Driver and a 1:1 IM Driver?
>
> and what are the advantages\disadvantages between choosing on or the
> other?
>
> (I.E in what scenarios would you chose one over the other)
>
> Thanks a lot for you time and help
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
A N:N IM driver is a 1:1 IM driver over multiple physical adapters. The IM driver can move packets between any virtual miniport to any physical adapter and vice versa.
We have an N:N IM driver for XP and older OS’s and a 1:N IM driver for Vista and above, both used for network fault tolerance.
Larry C
> whats the difference exactly between a N:1 IM Driver and a 1:1 IM Driver?
1:1 topology will allow you to write the Filter IM, not MUX IM.
Filter IM is 99.9% same in compiled code (the only difference is the “associate miniport” call which is IIRC not mandatory), but 100% different in install scripts and registry setup.
Unlike MUX IM, Filter IM does not require the notify object DLL.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Good points Maxim.
The 1:1(N:N) driver loads as a kernel service whereas the 1:N MUX driver loads as a protocol.
As for the Notify Object we do have a property page for our N:N driver but the code is a small number of lines compared to the driver. The Notify Object for the 1:N MUX, which includes a property page, must handle all the unbinds/binds for the install has a larger number of lines of code than the driver and is much more complicated.
Larry C
> The 1:1(N:N) driver loads as a kernel service whereas the 1:N MUX driver loads as a protocol.
What does it mean “loads as a kernel service” or “loads as a protocol”?
Both have the .sys file loaded and DriverEntry called.
The difference is in the registry structures, not in the load process.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
When you select the property page for a physical adapter and click on “Install” you have to pick the “type of network compnent you want to install”. The choices are “Client”, “Service” or “Protocol”. For the 1:1(N:N) driver choose “Service” and for the 1:N MUX choose “Protocol”.
That’s what I mean. Sorry if I was unclear.
Larry C
That’s true, Max. But remember that NDIS IM drivers are loaded indirectly
the NDIS wrapper and and the wrapper plays games with DeviceObject, etc.
For NDIS IM driver the choice of installing as a “protocol” or as a
“service” changes how NDIS loads the driver.
I don’t remember seeing a real description of the “meaning” of the choice of
“service” or “protocol” anywhere. Only directions to use one or the other as
specified in WDK.
Thomas F. Divine
From: “Maxim S. Shatskih”
Sent: Monday, January 23, 2012 11:51 AM
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Subject: Re:[ntdev] NDIS5 IM Driver Question
>> The 1:1(N:N) driver loads as a kernel service whereas the 1:N MUX driver
>> loads as a protocol.
>
> What does it mean “loads as a kernel service” or “loads as a protocol”?
>
> Both have the .sys file loaded and DriverEntry called.
>
> The difference is in the registry structures, not in the load process.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
The difference should be somewhere in binding rules,
and binding calls that NDIS makes.
Previously protocols could discover their underlying
components without help of NDIS, and bind themselves, which allowed a
really simple installation.
But that have been changed with NT6?
On 23-Jan-2012 19:24, Thomas F. Divine wrote:
That’s true, Max. But remember that NDIS IM drivers are loaded
indirectly the NDIS wrapper and and the wrapper plays games with
DeviceObject, etc.For NDIS IM driver the choice of installing as a “protocol” or as a
“service” changes how NDIS loads the driver.I don’t remember seeing a real description of the “meaning” of the
choice of “service” or “protocol” anywhere. Only directions to use one
or the other as specified in WDK.Thomas F. Divine
From: “Maxim S. Shatskih”
> Sent: Monday, January 23, 2012 11:51 AM
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Subject: Re:[ntdev] NDIS5 IM Driver Question
>
>>> The 1:1(N:N) driver loads as a kernel service whereas the 1:N MUX
>>> driver loads as a protocol.
>>
>> What does it mean “loads as a kernel service” or “loads as a protocol”?
>>
>> Both have the .sys file loaded and DriverEntry called.
>>
>> The difference is in the registry structures, not in the load process.
>>
>> –
>> Maxim S. Shatskih
>> Windows DDK MVP
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
The NDIS 6 ProtocolBindAdapterEx callback is significantly different from
the older NDIS 4/5 ProtocolBindAdapter call.
I remember the technique that you mention and used it successfully in NDIS
5. But lately I’ve just “gone with the flow” of the MS “approved” scheme.
Frankly, never tried to “spoof” protocol bind the old way. Might work, but
never tried it.
Thomas
From: “Pavel A”
Sent: Monday, January 23, 2012 2:21 PM
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Subject: Re:[ntdev] NDIS5 IM Driver Question
> The difference should be somewhere in binding rules,
> and binding calls that NDIS makes.
>
> Previously protocols could discover their underlying
> components without help of NDIS, and bind themselves, which allowed a
> really simple installation.
> But that have been changed with NT6?
> - pa
>
> On 23-Jan-2012 19:24, Thomas F. Divine wrote:
>> That’s true, Max. But remember that NDIS IM drivers are loaded
>> indirectly the NDIS wrapper and and the wrapper plays games with
>> DeviceObject, etc.
>>
>> For NDIS IM driver the choice of installing as a “protocol” or as a
>> “service” changes how NDIS loads the driver.
>>
>> I don’t remember seeing a real description of the “meaning” of the
>> choice of “service” or “protocol” anywhere. Only directions to use one
>> or the other as specified in WDK.
>>
>> Thomas F. Divine
>>
>>
>> --------------------------------------------------
>> From: “Maxim S. Shatskih”
>> Sent: Monday, January 23, 2012 11:51 AM
>> Newsgroups: ntdev
>> To: “Windows System Software Devs Interest List”
>> Subject: Re:[ntdev] NDIS5 IM Driver Question
>>
>>>> The 1:1(N:N) driver loads as a kernel service whereas the 1:N MUX
>>>> driver loads as a protocol.
>>>
>>> What does it mean “loads as a kernel service” or “loads as a protocol”?
>>>
>>> Both have the .sys file loaded and DriverEntry called.
>>>
>>> The difference is in the registry structures, not in the load process.
>>>
>>> –
>>> Maxim S. Shatskih
>>> Windows DDK MVP
>>> xxxxx@storagecraft.com
>>> http://www.storagecraft.com
>>>
>>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer