ExamGuru IT/.Net Guru : help me with my understanding of WSPRecv/From on microsoft.public.dotnet.framework.sdk

.NETGURU

help me with my understanding of WSPRecv/From

Messages

Related Types

This message was discovered on microsoft.public.dotnet.framework.sdk.

Harry Potter

I understand that LSP resides between the Wsock32.dll and TCP.sys... so if
the sequence to send is the following
App->Wsock32.dll->LSP->TCP.sys
send->WSASend->WSPSend->lpwspsend

then shouldn't the sequence to receive be the following
TCP.sys->LSP->WSock32.dll->App

what function called inside LSP by the TCP.sys to notify LSP of a receipt of
packet??
when I track the functions, I see WSPRecv and WSPRecvFrom called as the
first entry point, but If that's the case WSPRecv and RecvFrom are the upper
interface to the sock32.dll and they should be invoked by the app not the
Tcp.sys....
shouldn't there be a sort of an event dispatched to the sock32.dll from LSP
telling it that there is a data to pick up and then sock32.dll make a call
to WSPRecv and RecvFrom?
since the recv process starts from the low layer shouldn't there be a
sequence of event
TCP.sys fires an event notifying LSP that there is a buffer available
LSP reads the buffer and dispatches an event to sock32.dll and passes the
socket handler that was set previously
sock32.dll calls to WSPRecv or RecvFrom (determined which, using the
handler) and picks up the data
same process between the sock32.dll and application.

where am I wrong in my understanding.... hope not all:(

I would appreciate all your advise...
thank you in advices...

P.S. sorry for my posting in multiple groups... since it involves multiple
layers (low to high) I figured I would benefit from opinions from different
angles.

Reply to this message...

Maxim S. Shatskih

> I understand that LSP resides between the Wsock32.dll and TCP.sys... so if

Long explanation (a FAQ candidate :)):

WinSock is a user-mode layer (wsock32.dll and others below it) to provide
Berkeley Sockets-style API for the apps.
Besides Berkeley, WinSock has some MS-specific functions to employ the NT
kernel's async IO facilities better - like AcceptEx and so on.

Sockets API deals with protocol families (which determine the physical medium
below and the addressing format - so, also called "address families"). To
understand several address families, WinSock needs a Provider DLL for each -
like ODBC needs a "driver DLL" to talk to particular SQL engine.

Lots of address families (IPv4 and IPv6 included) are implemented in the
kernel-mode protocol driver with TDI upper edge. For such address families,
WinSock has a common provider DLL called MSAFD.DLL. It is nothing more then a
wrapper from WSPxxx routines called by WinSock upper layer to DeviceIoControl
calls to AFD.SYS.

AFD.SYS is a kernel module which implements the sockets semantics on top of
TDI. It implements things like SO_SNDBUF, SO_RCVBUF, SO_LINGER (all SOL_SOCKET
in fact), and listen backlog, to avoid re-implementing them in each transport.

Other OSes also have the analog of AFD. For instance, FreeBSD has a module with
soisconnected() and soreceive() functions, which are not tied to TCP/IP, but
called from inside the "netinet" TCP/IP code.

Now let's return to WinSock. So, if your implementation is a kernel driver with
TDI upper edge, then you already have AFD.SYS for you, and MSAFD.DLL WinSock
provider for you. This will give you lots of socket stuff, including all async
IO, FIONREAD, SO_SNDBUF, SO_RCVBUF, SO_LINGER, and listen backlog.

Nevertheless, some things are still not covered. They are your
protocol-speficic things like gethostbyname() or protocol-specific
non-SOL_SOCKET socket options (like TCP_NODELAY). To handle this, you must
write a Provider Helper DLL, which is loaded as a side add-on to MSAFD and
handles what MSAFD cannot. Usually, it does this by private IOCTLs to the
kernel protocol driver, which can even bypass TDI.

TCP/IP (AF_INET) family has such a DLL called WSHTCPIP.DLL, and its simplified
source named WSHSMPLE is in the DDK.

Now the second song. What if your protocol is not a kernel module at all? Or a
kernel module, but with no TDI upper edge? In this case, you cannot use MSAFD
and AFD.SYS, and thus will need to write your Provider DLL from scratch,
exporting all necessary WSPxxx functions.

There is also some subtle moment here. Lots of Win32 apps assumes that the
SOCKET value is the same as Win32 file handle, and are using the return value
of socket() in ReadFile or such.
With AFD (and thus TCP/IP), this works, since in this case SOCKET is a real
file handle pointing to inside AFD.SYS.

But, if your particular protocol has no kernel mode module, you will have
troubles with these apps which will use ReadFile on your socket handle. To
handle this, there is a WS2IFSL.SYS auxiliary driver and WPUCreateSocketHandle
function. This must be called by your provider's WSPSocket path. It calls
CreateFile on WS2IFSL.SYS and registers the resulting handle in WinSock. After
this, if any other app will do Read/WriteFile on this handle, WS2IFSL will
redirect them to the same process's WinSock DLLs and to your provider's
WSPSend/Recv which will do the real job.

If your protocol has the kernel mode part, but is not TDI, then you already
have a handle suitable for Read/WriteFile. Nevertheless, for routing of
setsockopt() to your particular DLL and some other purposes, the handle must be
registered in WinSock using WPUModifyIFSHandle. The provider's WSPSocket path
calls CreateFile on your kernel component, and then WPUModifyIFSHandle.

Now the third song. Layered service providers. They are "providers over
providers", like the stackable filters. Its job is to alter the functionality
of the base provider (usually MSAFD for TCP/IP).

Not so good a thing. Lots of TCP/IP traffic does not go via WinSock and thus is
invisible to LSP. All SMB traffic. PPTP/L2TP traffic. HTTP traffic on Windows
2003 webserver (http.sys). These kernel facilities talk directly to TDI upper
edge of TCPIP and bypass WinSock at all. Be prepared for this.

On Windows CE 4.2, SSL is implemented as a LSP - so, just call socket() with a
proper address family and you will have SSL. Dunno on usual Windows, maybe it
is also such.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
Click here to reveal e-mail address
http://www.storagecraft.com

Reply to this message...

Harry Potter

wow.... Maxim, this is not FAQ but a crash course:) thank you very much for
taking your time and provide such detail explanation...

and here are my few questions for the assurance...

[Original message clipped]

> Now the second song. What if your protocol is not a kernel module at all?
Or a
> kernel module, but with no TDI upper edge?
Q. but TCP is a kernel module with a TDI upper edge, right?

[Original message clipped]

when and app requesting HTTP/TCP or TCP or UDP call!!! then is this mean
that TCP/UDP doesn't have kernel module??? I'm quite sure this is wrong
conclusion from me.. but then what do you mean?

> After this, if any other app will do Read/WriteFile on this handle,
WS2IFSL will
[Original message clipped]

Q. ok, then when I see WSPRecv called on the incoming response from server
it is WS2IFSL that has caused invoking of WSPRecv ...

> Not so good a thing. Lots of TCP/IP traffic does not go via WinSock and
thus is
> invisible to LSP. All SMB traffic. PPTP/L2TP traffic. HTTP traffic on
Windows
> 2003 webserver (http.sys). These kernel facilities talk directly to TDI
upper
> edge of TCPIP and bypass WinSock at all. Be prepared for this.

Q..uuuuhhhhh... there you go... that could be the case!!! though I'm running
win 2000 pro...so if I want to trap all TCP request including (HTTP/TCP) and
alter them to redirect it to for example UDP then I should develop a TDI vs.
LSP??

Once again thank you for the thorough explanation.

Reply to this message...

Maxim S. Shatskih

[Original message clipped]

Yes, TCPIP.SYS and TCPIP6.SYS

> Q. but TCP is a kernel module with a TDI upper edge, right?

Yes.

[Original message clipped]

Dunno what LSP do you mean.

[Original message clipped]

You don't know. You just send the data.

[Original message clipped]

TDI filters are unsupported.
IIS has its own traffic filtering facility (ISAPI filters).

I would use (a very complex) NDIS IM driver for this - but it has a drawback of
not knowing what process owns what port.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
Click here to reveal e-mail address
http://www.storagecraft.com

Reply to this message...

Harry Potter

Thank you for the quick response..
[Original message clipped]

SDK Feb 2003. it's just an empty shell...I put debugging to track it...

"Maxim S. Shatskih" <Click here to reveal e-mail address> wrote in message
news:%23j2$Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification

Need Dot Net Interview Questions?
Ask ExamGuru, Inc. for advice and help on Passing .Net Interviews

.Net Projects
Best-of-breed application framework for .NET projects, developed by ExamGuru, Inc. and ExamGuru IT

Free .net Help
Commission ExamGuru, Inc. and his team for your next bespoke software project

FogBUGZ
The only bug tracking system carefully crafted with one goal in mind: helping teams create great software.

Awesome Tools
If you don't know about these, you're missing out... IT Certification Questions
IT Interview Questions
Free Oracle 10g Training
MCSE Boortcamp
Cisco Study Guides
Cheap Study Guides
Exact Questions
Dot Net Interview Questions
Oracle OCP
Cheap Travel
Designer Perfumes - Wholesale Prices
Free Programming Tutorials

	Copyright © ExamGuru, Inc. 2001-2006
	Contact Us - Terms of Use - Privacy Policy - www.dot-net-guru.com - www.examguru.net - www.oraclesource.net - www.itinterviews.net - www.examguru.net/ITCertification