New network transport and WSK integration

NTDEV
1

Hi everyone,

We need to write an SCTP stack.
We are aware of the existence of SctpDrv, but its source code is no longer publicly available, what makes it less usable for us.

We want the drivers in the new stack to integrate smoothly with Windows Vista+ networking as if it were Microsoft’s TCP/IP. That includes WSK and Winsock2.

But this kind of development is hard and it is difficult to find comprehensive documentation that covers the whole process. There are many documents that describe the usage of Windows’ next generation TCP/IP stack as a client, but very little about writing your own transport so that it has the same features as Microsoft’s.

Let me be more specific:
– Before Windows Vista, you could write an NDIS protocol driver that additionally implemented TDI.
– From Windows Vista on, TDI is deprecated, and developers are encouraged to choose between WSK and WFP. But the documentation adds: only TDI clients should switch to WSK. What about TDI providers?
– TDI clients are temporarily supported, via a driver that translates into WSK (TDX).
– WSK can consume TDI transports, but TCPIP.sys is no longer a TDI transport, and TDI usage is still considered legacy.
– We haven’t found any documentation on the interface implemented by TCPIP.sys and consumed by WSK that allows both layers to communicate.

My questions are:
– What NPI should an SCTP NDIS protocol driver implement so that it can be used by the WSK subsystem without resorting to TDI? I’m referring to the provider side of the equation, not the client side.
– What interface should the same NDIS protocol driver implement to be pluggable into Winsock2? Are Winsock2 base service providers still used for this kind of integration? Are the details of the communication between the service provider DLL and the protocol driver completely private, or are there any facilities or recommended interfaces in either side to ease the implementation?
– Are the efforts to integrate the stack with WSK and Winsock2 completely orthogonal to each other, or are there any measures that can bring them closer?

Thank you very much for your help.

Regards,

Jos?

2

Although I’m still interested in the development process to build a new transport provider that can be consumed by WSK, I’ve come to the conclusion that perhaps an SCTP kernel driver can be more easily implemented as a raw socket WSK client.

I still have to confirm that I can pass the value 132 as the Protocol to WskSocket in order to receive only raw packets related to SCTP.