Abolade Gbadegesin and team - Networking in Windows Vista | scobleizer

TrayJoe

This is great stuff guys. When I ran the McAfee Personal Firewall group we came up to Seattle in 2003 to talk about what we wanted to see in the stack to make implementing our products easier. Great to see not only that this has all worked out with the improvements over TDI, but the performance improvements as well.

So much stuff we used to have to do ourselves, now baked in. Very cool, but I remain glad I got out of that line of business Smiley

Is the deep stuff going to be exposed to .NET? Will it be possible to write complex security apps solely in managed code?

staceyw
Before C# there was darkness...

That sounds really great guys! Thank you. The team seems like a bunch of great folks. I have some questions on network stack regarding server side tech to allow easier server side code to be developed that will scale. This may be more socket and OS related, but I am sure it is all intermixed.

Today, to write a socket server, you pretty much have two models. You can have a thread per socket model which is easy to write, but does not (or can not) scale much beyond 1000 threads because of windows limitations and RAM. Fibers, may help here, but not sure, maybe some talk on that option. The other option is an Async server that handles IO with async reads and writes. This scales well, but is difficult to write and more difficult to prove its correctness and debug because of its disjointed nature (i.e. its hard). Another model that begs to work is to add sockets to a Wait event, so the event will signal when some IO is on a socket. This does not work beyond 64 objects and has some fairness issues IIRC, because of some limits in WaitForMultipleObjects.

It would seem like a simplier model may be to have some native SocketQueue that I could add thousands of sockets (if needed) to and be "called back" in an efficent manner for reads and writes. Maybe you handle the thread pool or we can spin up X number of threads that Wait for reads on the SocketQueue. Then I can still do my logic in some Syncronous way, but the system handles the async IO. Hope that makes some sense. Any work in this area? TIA
--
William Stacey [MVP]

Denton

One of the best interviews i've seen, these seem like a greate bunch of gyes that realy get into there work and have greate personalities. There is nothing more boring than when you interview someone with no sens of humour, not the case here, greate buch of gyes.

tragic_hip

I haven't finished watching yet, but a question about the comment about speed up on a DSL link. You would only see that improvement if you were directly connected to the internet and not connecting through a NAT/firewall ?

Are there any other OS's that support this change in the Transmission Control algorithim? Is it a MS only algorithim? Is there any possability that this will be back ported to XP?

mycroft

Sounds similar to the FAST improvements to TCP, getting rid of the overly cautious doubling of the delay when acknowledgements are late. Don't know if it's the same thing. Apparently , while TCP has max 25% throughput, FAST can achieve 95% efficiency.

http://netlab.caltech.edu/

programcsharp

Is the new firewall going to be able to take advantage of integrated hardware firewall processors, like the nForce firewall?

MegaTrain

Great video. Best combination of accents in one room... Big Smile

skaniyar

You may want to take a look at the IO Completion port architecture – that will let you work with thousands of sockets on very few threads and the programming model is quite intuitive.

Thanks.

skaniyar

My previous response was to staceyw.

Tragic_hip: if the firewall/NAT is doing IP level forwarding/natting ONLY, then the improvements will work through them as well. On the other hand, if that device is doing split TCP connection, it may not.

The new congestion control algorithm is Microsoft’s intellectual property. We have not explored the possibility of backporting this to XP yet.

MyCroft: This is not FAST – it is called CTCP (Compound TCP).