Anyone would like to chip in !
I’m thinking about getting SCTP in kernel ( user mode libraries and
sources are avail), but it would be nice if I could get some design (
actually crafting idea ) into kernel ( just would sit on top of IP layer
). User mode implementations are basically a simulation type approach on
top of UDP mainly …
More I look at it ( the ddk area), more it hurts my brain :-).
BTW, Linux ( oops ) has a kernel implementation.
Requirment:: Mainly due to telephony signaling ( time sensitive )
-pro
> I’m thinking about getting SCTP in kernel ( user mode libraries and sources are avail), but it would be >nice if I could get some design ( actually crafting idea ) into kernel ( just would sit on top of IP layer ).
Well, apparently, you would need to present yourself as:
- On the upper edge, TDI transport provider that exposes your protocol to Winsock via AFD.SYS
2.On the lower edge, TDI client that deals with TCPIP.SYS
At the same time, I am not sure you will be able to run the line like
socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP );
because, from AF_INET provider’s (i.e. TCPIP.SYS) perspective, IPPROTO_SCTP provider (i.e. your driver) is just a TDI client, rather than a protocol associated with AF_INET address family. Therefore, there is a good chance that a client will have to specify your address family,rather than AF_INET, as a first
parameter to socket()…
BTW, Linux ( oops ) has a kernel implementation.
Well, Linux allows you to associate your protocol with AF_INET address family…
Anton Bassov
>
socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP );
From socket interface this is a must though!
because, from AF_INET provider’s (i.e. TCPIP.SYS) perspective, IPPROTO_SCTP provider (i.e. your driver) is just a TDI client, rather than a protocol associated with AF_INET address family. Therefore, there is a good chance that a client will have to specify your address family,rather than AF_INET, as a first
parameter to socket()…
I was thinking to fork-out after IP layer (on the upperside). Seems like
there is a coupling (TCP + IP )that would not allow me to do so …
Well, Linux allows you to associate your protocol with AF_INET address family…
This should be the case …
Let me look a bit more, just got finished with SSL over SIP and
reasonably happy…, need a little time to page-my-memory-out/get clean
context 
-pro
At 15:40 11/10/2008, Prokash Sinha wrote:
>socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP );
>
From socket interface this is a must though!
One way that might achieve this would be to write a Winsock layered
provider so that you layer over the top of all the existing AF_INET protocols.
The existing protocols you can simple pass on to the usual provider,
for SCTP you pass directly to your protocol provider.
Mark
Mark S. Edwards wrote:
> From socket interface this is a must though!
One way that might achieve this would be to write a Winsock layered
provider so that you layer over the top of all the existing AF_INET
protocols.
The existing protocols you can simple pass on to the usual provider,
for SCTP you pass directly to your protocol provider.
It seems like the way to go …
OTOH:-
(0) The SCTP socket interface could be in UM library.
(1) The top level (as you suggested) LSP will have the forking for SCTP.
(2) Not sure about the KM here, since SCTP have a dependency on IP
(architecturally)!. Otherwise, it could have been a good candidate as a
protocol driver ( in NDIS terminology !)
-pro
> From socket interface this is a must though!
Well, this is understandable - this is why I said you need to register TDI provider. What I am speaking about here is the first argument to socket(), i.e. AF_INET - unless you somehow manage to associate your protocol with AF_INET family(which seems to be rather problematic), your transport provider will be totally unrelated to AF_INET, from AFD’s perspective. Therefore, you will have to provide a name of your address family, rather than AF_INET. Your address family will internally rely upon AF_INET, but clients don’t have to know it - they can think of it as of some new AF…
Anton Bassov