Re: Could this be implemented with an NDIS or TDI driver?

From: Maxim S. Shatskih (maxim_at_storagecraft.com)
Date: 04/11/04 

Date: Sun, 11 Apr 2004 19:31:40 +0400

> As Thomas points out, the advantage to being above the
> stack is that you see reassembled data.

Not really an advantage. Anyway you see the portions of the stream as delivered
to ClientEvent(Chained)Receive.

> cause performance problems, and can be different on the
> various versions of Windows.

TDI is same on all Windows NT versions. Our kernel sockets code runs unmodified
from NT4 to XP.

> applications use Winsock, there are some, especially
> certain ones provided by Microsoft, that use TDI

Namely - SMB redirector and server, Services For Macintosh server, and IIS in
w2k3 (http.sys).

> Below the stack, you do have the issue of reassembly.

Dropping out-of-order packets can help for the first time, though can possibly
decrease performance a bit. Anyway I don't think it will cause much decrease,
being nearly the same as the absense of SACK TCP option (not supported by MS
till w2k).

Anyway such software is to guard user Internet access - rarely more then around
7Mbit/s - so, such a drop can go unnoticed.

> However, depending on what you're filtering for, you may
> be able to keep packet to packet state that lets you
> avoid implementation of TCP reassembly.

Yes.

> Windows). Because most VPN clients use DNE

Microsoft's especially :-)

> signature, you can avoid the time-consuming and costly
> process of certifying your driver with WHQL.

There is no need in certifying the networking stack plugin with WHQL. 

-- 
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Relevant Pages

  • Re: singe thread per connection
    ... process is about 2000, with the practical maximum somewhat lower, and performance suffering significantly before that. ... If you use a different stack size than the default, or don't actually allocate one OS thread per Java thread, then the actual limit would be different. ... But in Windows, both in the regular Win32 API and under .NET, there are i/o mechanisms that can be used that allow a single thread to service an arbitrarily large number of i/o tasks. ... This allows a program to create just enough threads to keep all the CPU cores busy, and the Windows scheduler knows to treat those threads specially so that if the only other runnable thread is one that would do the same thing that the currently running thread would do, the currently running thread is allowed to just keep running, rather than being preempted for no good reason. ...
    (comp.lang.java.programmer)
  • Re: Iczelions tutorials revisited.
    ... By "local" variables on the stack I assume something like this? ... access parameters and locals that way. ... The Windows API uses "stdcall" in which "callee cleans up stack" - the Windows functions end with "ret N". ... Being an old dos-head, I'm used to using cx as a "counter", and it annoys me that calling libc or the Windows API is allowed to trash it, but that's life... ...
    (alt.lang.asm)
  • Re: Is MASM32 an evil Microsoft plot?
    ... Now your next blunder is to call the default windows message handler ... > you could use most any assembler and the whole advocacy for MASM disappears. ... C3;; retn ... Is there supposed to be some profundity at addressing the stack ...
    (alt.lang.asm)
  • Re: IPAQs and Bluetooth and Visual Studio 2005 beta 2
    ... Differences between WinCE and Windows Mobile: ... Note that if you don't have a device running the Microsoft Bluetooth stack, ...
    (microsoft.public.pocketpc.developer.networking)
  • Re: Need some help understanding array definitions
    ... their Windows product, ... Windows and DLL calls, and I'm sure MPE's equivalents address the same ... space available on the return stack at any given time. ... We don't have ALLOCATE or local buffers, ...
    (comp.lang.forth)