SMB gets in my way

NTFSD
1

Hi,

I have an IFS client implementing remote file access using a proprietary
protocol. The remote paths are exposed to users as UNCs, e.g.
\srv3.myplace.com\MyVol\file.txt

When the server (srv3.myplace.com in the example) has no firewall, things
work great. However, when the server blocks all ports except for the one
used for the client/server comm, the client’s performance becomes
terrible.

I believe that the reason for that is the native SMB protocol on the
client machine. When a UNC such as the one above is used, the O/S polls
each of the network providers. My provider recognizes it immediately as
“its” path. But SMB tries to talk to the remote server, and since the
remote server’s SMB port is closed, the SMB network provider eventually
times-out. The O/S must wait for this time-out, hence the dismal
performance.

When the SMB port on the remote machine is opened, the SMB dialog with the
server is fast, so it returns a “not my UNC” status very quickly.

Does anyone know if there’s a way on the client to disable SMB traffic to
the specific server’s domain? Or maybe another solution?

thanks,
Chuck Shavit

2

Please see Rajeev’s book Windows NT File System Internals page 62. It
discusses this topic in details.

3

Chuck,

There are two registrations involved here:

(1) The registration as a UNC provider; this is what the FSD does so that
MUP will send UNC names (“\” at the beginning) to it. These are called in
the order of registration which is normally the order of loading.

(2) The network provider DLL. This is what MPR (multi-provider router)
calls when you are browsing using the shell. These are called in the order
they are listed in the registry.

Thus, to resolve the issue you are discussing, you should change your
ordering here - for both of these. That will eliminate your timeouts.

Regards,

Tony

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

-----Original Message-----
From: Chuck Shavit [mailto:xxxxx@MagicSquare.com]
Sent: Monday, April 15, 2002 10:41 PM
To: File Systems Developers
Subject: [ntfsd] SMB gets in my way

Hi,

I have an IFS client implementing remote file access using a proprietary
protocol. The remote paths are exposed to users as UNCs, e.g.
\srv3.myplace.com\MyVol\file.txt

When the server (srv3.myplace.com in the example) has no firewall, things
work great. However, when the server blocks all ports except for the one
used for the client/server comm, the client’s performance becomes
terrible.

I believe that the reason for that is the native SMB protocol on the
client machine. When a UNC such as the one above is used, the O/S polls
each of the network providers. My provider recognizes it immediately as
“its” path. But SMB tries to talk to the remote server, and since the
remote server’s SMB port is closed, the SMB network provider eventually
times-out. The O/S must wait for this time-out, hence the dismal
performance.

When the SMB port on the remote machine is opened, the SMB dialog with the
server is fast, so it returns a “not my UNC” status very quickly.

Does anyone know if there’s a way on the client to disable SMB traffic to
the specific server’s domain? Or maybe another solution?

thanks,
Chuck Shavit

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

4

> Does anyone know if there’s a way on the client to disable SMB traffic to

the specific server’s domain? Or maybe another solution?

You can toggle the network provider order in the Control Panel.

Max

5

Thanks Tony for the detailed reply. I still have two questions.

  1. I can easily control the order in the registry (your item #2). How do
    I control the order of MUP registration (your item #1)?

  2. I understood that the order discussed above determines the *priority*,
    i.e., which provider is used when more than one claims the UNC. But I
    also understood that MPR calls all the providers in parallel, and waits
    for their reply. Is it true? Because if so, MPR will call SMB
    unconditionally even though my provider had already claimed the UNC, and
    thus MPR will wait for SMB’s reply which will only come after a very long
    delay (20 seconds or so).

Thanks
Chuck Shavit

Chuck,

There are two registrations involved here:

(1) The registration as a UNC provider; this is what the FSD does so that
MUP will send UNC names (“\” at the beginning) to it. These are called in
the order of registration which is normally the order of loading.

(2) The network provider DLL. This is what MPR (multi-provider router)
calls when you are browsing using the shell. These are called in the order
they are listed in the registry.

Thus, to resolve the issue you are discussing, you should change your
ordering here - for both of these. That will eliminate your timeouts.

Regards,

Tony

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

-----Original Message-----
From: Chuck Shavit [mailto:xxxxx@MagicSquare.com]
Sent: Monday, April 15, 2002 10:41 PM
To: File Systems Developers
Subject: [ntfsd] SMB gets in my way

Hi,

I have an IFS client implementing remote file access using a proprietary
protocol. The remote paths are exposed to users as UNCs, e.g.
\srv3.myplace.com\MyVol\file.txt

When the server (srv3.myplace.com in the example) has no firewall, things
work great. However, when the server blocks all ports except for the one
used for the client/server comm, the client’s performance becomes
terrible.

I believe that the reason for that is the native SMB protocol on the
client machine. When a UNC such as the one above is used, the O/S polls
each of the network providers. My provider recognizes it immediately as
“its” path. But SMB tries to talk to the remote server, and since the
remote server’s SMB port is closed, the SMB network provider eventually
times-out. The O/S must wait for this time-out, hence the dismal
performance.

When the SMB port on the remote machine is opened, the SMB dialog with the
server is fast, so it returns a “not my UNC” status very quickly.

Does anyone know if there’s a way on the client to disable SMB traffic to
the specific server’s domain? Or maybe another solution?

thanks,
Chuck Shavit

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%