I have read about NDIS in MSDN documentation.
But still can't understand link between application (which use winsock2) and drivers (filter, protocol, intermediate, miniport). How data transferred from app to drivers? Usually app use connect, send, receive and other functions of Winsock2. And how this interference with IRP, MDL, NET_BUFFER_LIST?
To simplify, I need to split traffic - some traffic goes to one adpater and some traffic to second adapter.
As I understand I need intermediate driver to do this. So I can have one virtual adapter which have two physical adapters at the lower edge. This is MUX IM adpater 1-to-N.
I even can't form my question correctly. Thus I asked about transferring data between app and driver stack.
The "how" is just like every other driver interface. The code for connect, send, receive, etc. within Winsock2 converts those calls into IRPs and sends them to the appropriate top-level network driver. From then on, they just travel down the stack of filter drivers until they get to a hardware driver.
If I understand correctly. Winsock selects upper level protocol driver depending on used protocol parameter in socket() function call. When app calls send() winsock converts it to WriteFile() (or similar) with handle of protocol driver, and after that protocol driver call NdisSendNetBufferLists to send data down the stack?
If so, on NDIS layer we lost IRP structure and have only NBLs?
Pretty much. Remember that NDIS was designed to be operating system agnostic. NDIS drivers could run on Windows CE, which did not use IRPs, and can even be loaded on Linux systems, which also do not use IRPs. They are a world unto themselves.
Now, it's POSSIBLE that the NDIS port drivers use IRPs behind the scenes to pass NBLs from one layer to another, but I'm not enough of a network guy to know that.
There is too much to go over in a simple post. But here are some basics.
SOCKET handles are IFS handles just like file handles etc. The winsock API is a UM library that exposes the standard socket functions (plus some Microsoft extensions) and converts them into WriteFile and similar calls. Applications can make those calls directly and often do
sockets are implemented by protocol drivers. Almost always TCP or UDP over IP. Protocol drivers are responsible for converting data sent from the application into packets that can be sent on the network, and converting packets from the network back into data that the application can use. with UDP/IP that is a simple process, but with TCP/IP it is not.
If you want to split traffic between different network adapters, your most difficult task is to decide why a certain packet should go one way or the other. Usually some sort of hash of the IP addresses & ports is used so that packets that belong to a single connection are all routed in the same way.