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+?

  • Jay

AFD is the file system (on Windows NT/2000) that supports sockets. Thus,
you will get back a file object from a socket handle (if you get anything.)
For TCP/IP you will get back a file object.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----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+?

  • Jay

The MS implimentation of sockets for tcp /ip / udp are represented by a
FILE_OBJECT, therefore you can use the ReadFile, WriteFile api’s. Other
partys that impliment their own transport providers do not have to
follow this model.

APN

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jay Krell
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+?

  • Jay

You are currently subscribed to ntfsd as: xxxxx@hartingdale.com.au
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

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+?

  • Jay

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.

> 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."

MS got rid of it in some SP to NT4. (SP4?)
They added a driver called ws2ifsl.sys (Winsock IFS Layer) to the OS to
emulate file handles for WinSock providers for which socket handle != file
handle.
Anyway:

  • the default Winsock provider used by all MS stacks - afd.sys + msafd.dll
    (which is in fact a brigde between Winsock and kernel-modeTDI interface) -
    gurantees that sockets are file handles.
  • nonMS network stacks on NT are very, very rare.

Max