Re: SMB handler - kind of
- From: "Volodymyr Shcherbyna" <v_scherbina@xxxxxxxxxxxxxxx>
- Date: Mon, 11 Feb 2008 11:38:46 +0100
Since your question is related to networking staff, I did an answer at
microsoft.public.win32.programmer.networks. If you need any more answers -
ask questions there.
--
V
This posting is provided "AS IS" with no warranties, and confers no
rights.
"eric" <eselk@xxxxxxxxxxxx> wrote in message
news:89a4a76b-454a-419c-8958-87e8b250bab1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I have a client/server model that uses named-pipes. The client hooks
all file i/o calls before they go to kernel32.dll, like CreateFile and
ReadFile. Instead of sending them to kernel32.dll, it uses
TransactNamedPipe to send the request (and get reply) to my module/EXE
that runs as a service on another PC (the server).
Now, I can get my module to be *almost* as fast as the system's SMB
handler (network redirector? or whatever you call it). I think the
last remaining reason it isn't as fast (and I've done profiling which
I think proves this), is because of the extra transitions between user
and kernel mode. For a normal ReadFile call, over a LAN, you have 1
transition to kernel mode, and 1 back to user mode (since both the
client and server side network stuff runs in kernel mode). With my
design, I end up with double that, and actually even tripple if you
include the service's call to do the actual file i/o (one more round-
trip).
My question, finally, what would be the easiest and/or best way to
eliminate these transitions? What kind of work would be required to
change my service to a driver, so it runs in kernel-mode? What kind
of driver would I write for that, obviously not a video driver, but
what category would it fall under?
I'm doing all of this so that a client can access a path like \
\FakeServer\servername\file.ext, even though the path doesn't really
exist, and the server doesn't even have the real file/folder shared.
This way only my client application can access files, but the user
cannot access them via Windows Explorer or any other process. The
hooks on the client side redirect everything to \\FakeServer\ to a
named pipe opened at the server.
Is there a way to filter SMB packets on the server? It would probably
need to be a kernel-mode filter, so it doesn't slow down all SMB
traffic. If so, that would also accomplish my goal... would that be
easier, or more work? Then the path on the client would look
something like \\RealServer\FakeFolder\file.ext, and the server could
modify the SMB packets and convert \FakeFolder\ to the real location
(I would have some method for a process to authenticate first, and
only do the conversion for authenticated process IDs (since packets
contain process IDs)).
.
- References:
- SMB handler - kind of
- From: eric
- SMB handler - kind of
- Prev by Date: Re: check whether the device is mounted ?
- Next by Date: Re: Critical section leak in advapi32.dll
- Previous by thread: SMB handler - kind of
- Next by thread: stack trace
- Index(es):
Relevant Pages
|
