At 08:49 AM 2/25/2000 -0500, you wrote:
-----Original Message-----
From: Jay Krell [mailto:xxxxx@cornell.edu]
Sent: Friday, February 25, 2000 3:28 AM
To: File Systems Developers Interest List
Subject: [ntfsd] Re: ntfsd digest: February 24, 2000
>What kind of object does ObReferenceObjectByHandle on a socket give me?
I’m not very familiar with sockets or Windows sockets, but…
MSDN says:
“A socket handle can optionally be a file handle in Windows Sockets 2. It is
possible to use socket handles with ReadFile, WriteFile, ReadFileEx,
WriteFileEx, DuplicateHandle, and other Win32 functions. Not all transport
service providers support this option. For an application to run over the
widest possible number of service providers, it should not assume that
socket handles are file handles.”
and
“Socket Data Type
A new data type, SOCKET, has been defined. This is needed because a Windows
Sockets application cannot assume that socket descriptors are equivalent to
file descriptors as they are in UNIX.”
so it sounds like if a SOCKET is a handle at all, it is a handle to a
FILE_OBJECT. How widely valid is this assumption? For at least TCP/IP
sockets on Win9x and NT4+?
The first implementation of the data type SOCKET or socket handle in
windows was in Windows 3.x. On this platform these were just whatever
numbers the underlying stack vendor decided to give to them.
When Microsoft added TCP/IP to NT, they created their stack to be part of
the o/s and to use the same o/s objects as any other file system in
NT. What they forgot about were that there were other vendors out there,
not just of TCP/IP but of other protocols too.
Most of the problems occur on Win95/98, but are present on pre-SP4 versions
of NT 4. The Winsock 2 spec allows for providers to create sockets that
are either IFS objects or non-IFS objects. Obviously, the Microsoft stack
provides IFS objects and as such functions like WriteFile and
DuplicateHandle will generally work.
These functions will fail if the socket handle is not an IFS handle. One
really ought to look in the protocol_info structure about the protocol in
use before attempting to use some of the functions that Microsoft lists as
available to socket handle that aren’t in the Winsock spec.
One might assume that the vast majority of machines will be running the
Microsoft stack and that you will never encounter a non-IFS handle. This
is not the case. The Winsock spec allows for the use of layered providers
that can add functionality over a base provider such as the MS
stack. Because layered providers are implemented in user mode, the handles
that they provide are de fact non-ifs handles. Just installing the sample
layered provider from MSDN, which actually adds no functionality is enough
to kill pre-SP4 versions of NT where some system components, notably RPC,
assume that all socket handles are IFS handles. e.g. Calling
Read/WriteFile bypasses the Winsock layers and goes direct to the device,
if the socket handle is non-IFS there is no device, but Read/WriteFile
don’t know that.
The fix in SP4 was to add a new driver that could turn non-IFS handles in
to IFS handles. This driver has the added effect of catching all calls
made to Read/WriteFile, throwing them back to user mode where they are
re-issued as WSARecv/Send calls.
If you are using Read/WriteFile on socket handles, you’re doing twice as
many ring transitions as you think you are.
The assumption that a socket is a handle to a FILE_OBJECT is more unlikely
under Win9x where there are still multiple vendors supplying that
market. For NT it can only be assumed to be true after SP4.
HTH,
Mark.