How to associate an Ndis Protocol Handle with a Binding Handle?

Discussion in 'Windows Vista Drivers' started by QuasiCodo, Sep 29, 2003.

  1. QuasiCodo

    QuasiCodo Guest

    What I'd like to do is have several instances of a protocol driver
    registered with NDIS. The problem I am having is associating the
    NdisProtocolHandle (returned from NdisRegisterProtocol()) with the
    BindingContext given to ProtocolBindAdapter(). Since NdisRegisterProtocol()
    does not take a user context as a parameter and there is no user context
    passed into ProtocolBindAdapter(), it is impossible to tell which binding
    context belongs to which protocol handle. Any ideas?

    ((&-<
     
    QuasiCodo, Sep 29, 2003
    #1
    1. Advertisements

  2. QuasiCodo

    Rohit Raina Guest

    You should be having only one instance of the Protocol driver...
    What is the real problem that you are trying to solve.

    -Rohit
    "This post is provided as is and confers no rights or warrenties."
     
    Rohit Raina, Sep 29, 2003
    #2
    1. Advertisements

  3. NdisRegiaterProtocol really says "I'm a Protocol Driver! Bind one (or more)
    adapters to me, please!".

    Later your BindAdapterHandler will be called zero (or more) times for the
    adapters that you can bind to. It is only at the point that
    BindAdapterHandler is called that you can make any association with specific
    miniports.

    Hope this helps.

    Thomas F. Divine
    www.ndis.com
     
    Thomas F. Divine, Sep 29, 2003
    #3
  4. QuasiCodo

    QuasiCodo Guest

    I have several remote hub devices which run a custom protocol. Because of
    the driver architecture (i.e. each hub has it's own instance of a WDM hub
    driver running), I wanted to have a separate instance of the protocol for
    each hub device with which I communicate. This, in theory, would simplify
    the interface to the upper-layer hub device driver. One benefit that I can
    think of off the top of my head is that the
    ProtocolReceive()/ProtocolTransferDataComplete() would only have to do a
    single compare of the source MAC address to determine if the packet belongs
    to "this instance" of the protocol. If this was a single instance of the
    protocol, then I have to do a table lookup to determine on which interface
    to send this packet (which is how the old driver works currently).

    Even though Ndis allows me to register multiple instances of a protocol in a
    single driver, it does not seem to outwardly support such an architecture
    (since NdisRegisterProtocol() has no user context parameter). It was worth
    a try a least.

    ((&-<
     
    QuasiCodo, Sep 29, 2003
    #4
  5. Humm...

    Prehaps you shouldn't give up completely.

    In theory you could use a NotifyObject to control the bindings to each of
    your per-hub NDIS protocol drivers. It would be the job of the NotiryObject
    to understand what your desired binding were and to insure that each
    logically distinct protocol was called at its BindAdapterHandler with the
    one-and-only adapter desired for that WDM hub.

    Alternatively, it may be possible for each protocol to go ahead and be
    called to bind on all adapters. However, each would actively use only one
    specific binding out of all offered. I suspect that you may be able to
    unbind unwanted bindings. I am not sure - but I believe that as long as you
    have made at least one binding your protocol will remain loaded. You would
    have to invent some binding selection method in this case.

    (I think that a single protocol and the table lookup is a lot easier to
    implement in the final analysis...)

    Thomas F. Divine
     
    Thomas F. Divine, Sep 30, 2003
    #5
  6. In Windows, multiple instances of a "driver" do not run.What is the
    benefit -- since it is the same code base. Also, I am not sure how would you
    register multiple instances of a protocol. If you use NdisRegisterProtocol
    multiple times, then make sure you have multiple INF files, corresponding to
    each "instance" (or Name ) you have provided in protocol characteristics
    structure(see below), because, it has to be same as the "service" of the
    protocol..., and if you do that, that makes it multiple protocols again...
    (
    Name
    An NDIS_STRING type containing a caller-initialized counted string, in the
    system-default character set, naming the driver. For Windows 2000 and later
    drivers, this string contains Unicode characters. That is, for Windows 2000
    and later, NDIS defines the NDIS_STRING type as a UNICODE_STRING type. This
    string must match that specified in the registry (under Services) when the
    protocol was installed.
    )

    Rohit
    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Rohit Raina [MS], Sep 30, 2003
    #6
  7. QuasiCodo

    QuasiCodo Guest

    Actually, the idea is that each instance of the protocol would bind to all
    adapters in the system. This way, if a hub is then disconnected and
    reattached somewhere else in the network, then we could switch from one NIC
    to another to talk to it. The algorithm required to keep track of a single
    device is much easier than tracking several device. For instance, if you
    haven't seen a packet from a Hub device for some time, it is logical to send
    a "connection keep-alive" packet to it to insure that it is still there. To
    do this with one Hub device per "thread" is easier than one thread handling
    all IO.

    The original designer of the new WDM driver architecture felt that perhaps
    multiple protocol instances would simplify the protocol design and alleviate
    the network bottle neck we are seeing in our current monolithic driver.

    What I was trying to do was register a new instance of the protocol during
    MN_START_DEVICE in the network-layer driver. This would create a 1:1
    correspondence between each protocol instance and each hub device instance.

    However, if I have to, I can use one instance of the protocol which can be
    registered during DriverEntry(). Then at MN_START_DEVICE, I can easily
    create a new entry in a routing table. Then during
    ProtocolReceive()/ProtocolUpdateDataComplete() I can do the table lookup and
    route the packet to the correct FDO.

    I'll look into NotifyObject to see if it could help me with the multiple
    protocol instance design.

    ((&-<
     
    QuasiCodo, Sep 30, 2003
    #7
  8. QuasiCodo

    QuasiCodo Guest

    In Windows, multiple instances of a "driver" do not run.

    I guess in WDM terms you would call this separate DevNodes or FDOs. I just
    think of them as "instances" because that is the term I used back in the old
    Win32 days of app programming.
    multiple INF files

    This works fine with only 1 protocol inf file. NdisRegisterProtocol()
    returns a different NdisProtocolHandle to each FDO which registers. For
    instance, I currently have only one NIC card in the PC. When my first FDO
    calls NdisRegisterProtocol(), Ndis returns an NdisProtocolHandle and then my
    ProtocolBindAdapter() gets called for the one NIC. Then when my second FDO
    (same driver, same code, same data space, different DevNode) calls
    NdisRegisterProtocol(), Ndis returns a different NdisProtocolHandle and then
    calls my ProtocolBindAdapter() yet again for the on NIC in the PC.

    My problem is that I want to associate my FDO Device Extensions (which, by
    the way, contains the NdisProtocolHandle) with the BindContexts given me in
    ProtocolBindAdapter(). Right now, the only way to do this is to set a
    global variable indicating which FDO is currently registering and waiting
    for BindsComplete. This is not good, since you should never assume that
    ProtocolBindAdapter() was called for-and-in-behalf of a certain
    NdisProtocolHandle.

    ((&-<
     
    QuasiCodo, Sep 30, 2003
    #8
  9. QuasiCodo

    Stephan Wolf Guest

     
    Stephan Wolf, Oct 1, 2003
    #9
  10. QuasiCodo

    Stephan Wolf Guest

    Sorry but I don't get what you're trying to do. You want to bind all
    your (not currently existing) protocol instances to all NICs, that is
    m-to-n bindings?

    Again, I seem to not fully understand your problem. But I am pretty
    sure there is a much simpler solution for it than having multiplt
    "instances" of your protocol.

    For instance, there can be many TCP connections all going to and from
    the same NIC. The TCP protocol stack demultiplexes any incoming
    packets by looking at the TCP port number field. Thus, some "table
    lookup" or whatever is always required and just the usual way how this
    is implemented.

    Stephan
     
    Stephan Wolf, Oct 1, 2003
    #10
  11. QuasiCodo

    Duh Pohmelja Guest

    AFAIK, ther should be no problem.
    You can easily "lookup" for which protocol PtBindAdapter is called, if
    you help 'em with Notify Object: just name your protocols
    "MyProto#1", "MyProto#2", ... and while doing binding in NObj - write
    something like "BoundProtocol"="MyProto#2" key to the registry. You can
    read that key in PtBindAdapter by using NdisReadConfiguration functions
    and this way you will determine which protocol is binding to that adapter.
     
    Duh Pohmelja, Oct 1, 2003
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.