Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MsQuic – QUIC Implementation from Microsoft

github.com

Post reply on HN
Print view View original

11–20 of 87 posts

Re: MsQuic – QUIC Implementation from Microsoft

#11

Post by slowstart »

tialaramex wrote: post #9
slowstart wrote: post #4

Please fire away any questions you may have! I lead the team that built this library. This blog has details on current development status and adoption within Microsoft: https://techcommunity.microsoft.com/t5/networking-blog/msqui...

Any strong reasons you chose C? Maybe I skimmed too quickly but I didn't see this mentioned in that blog post. Was there a requirement from other teams?

Since this had to run in kernel mode on Windows to power our HTTP stack, C was the language of choice. There exist other open source implementations of QUIC in C++ and Rust etc.

Re: MsQuic – QUIC Implementation from Microsoft

#12

Post by battery_cowboy »

vorpalhex wrote: post #8
battery_cowboy wrote: post #5

Earlier quoted context omitted.

I'm with you, and I'm happy that it seems like they are trying to become a good steward in the software industry. I am impressed by the quality of Windows 10, up to about a year ago I used Linux daily because it was a better experience than Windows 98 through 8.1, until recently. Lately, I find it's way easier to run Windows 10 with WSL rather than screw around with Linux trying to get things to work correctly that I…

Even during the evil days Microsoft occasionally produced great software like Microsoft Money. Like any large corporation, MS is not a single cohesive entity and I suspect the Win10 group pushing metrics and Cortana is not the same folks writing nifty quic implementations.

Exactly! I loved Microsoft money, BTW, I wish it was still a thing.

Re: MsQuic – QUIC Implementation from Microsoft

#14

Post by saagarjha »

slowstart wrote: post #11
tialaramex wrote: post #9

Earlier quoted context omitted.

Any strong reasons you chose C? Maybe I skimmed too quickly but I didn't see this mentioned in that blog post. Was there a requirement from other teams?

Since this had to run in kernel mode on Windows to power our HTTP stack, C was the language of choice. There exist other open source implementations of QUIC in C++ and Rust etc.

Since this is going in the kernel and is exposed to the network, what kinds of things are you doing to prevent security or reliability bugs due to undefined behavior?

Love the username, by the way :)

Re: MsQuic – QUIC Implementation from Microsoft

#15

Post by MrBuddyCasino »

slowstart wrote: post #11
tialaramex wrote: post #9

Earlier quoted context omitted.

Any strong reasons you chose C? Maybe I skimmed too quickly but I didn't see this mentioned in that blog post. Was there a requirement from other teams?

Since this had to run in kernel mode on Windows to power our HTTP stack, C was the language of choice. There exist other open source implementations of QUIC in C++ and Rust etc.

Isn’t the Windows kernel C++?

Re: MsQuic – QUIC Implementation from Microsoft

#16

Post by chungy »

battery_cowboy wrote: post #12
vorpalhex wrote: post #8

Earlier quoted context omitted.

Even during the evil days Microsoft occasionally produced great software like Microsoft Money. Like any large corporation, MS is not a single cohesive entity and I suspect the Win10 group pushing metrics and Cortana is not the same folks writing nifty quic implementations.

Exactly! I loved Microsoft money, BTW, I wish it was still a thing.

While not in active development, you can still download the Sunset Edition for free.

Re: MsQuic – QUIC Implementation from Microsoft

#17

Post by slowstart »

fulafel wrote: post #10

In the FAQ it says this is going into the Windows kernel. Is there a sockets api emerging for QUIC or will each impl have its own api?

There is currently no standardization for QUIC APIs. You can check out the MsQuic API here: https://github.com/microsoft/msquic/blob/master/docs/API.md

Re: MsQuic – QUIC Implementation from Microsoft

#18

Post by slowstart »

saagarjha wrote: post #14
slowstart wrote: post #11

Earlier quoted context omitted.

Since this had to run in kernel mode on Windows to power our HTTP stack, C was the language of choice. There exist other open source implementations of QUIC in C++ and Rust etc.

Since this is going in the kernel and is exposed to the network, what kinds of things are you doing to prevent security or reliability bugs due to undefined behavior? Love the username, by the way :)

We do extensive testing including stress testing and make use of tooling that can catch bugs early. We also partner with internal security teams to do fuzz testing and security reviews for all networking code. That said, none of the networking stacks deployed widely today are completely immune to security vulnerabilities. Responsible disclosure also plays an important role.

Re: MsQuic – QUIC Implementation from Microsoft

#19

Post by __s »

saagarjha wrote: post #14
slowstart wrote: post #11

Earlier quoted context omitted.

Since this had to run in kernel mode on Windows to power our HTTP stack, C was the language of choice. There exist other open source implementations of QUIC in C++ and Rust etc.

Since this is going in the kernel and is exposed to the network, what kinds of things are you doing to prevent security or reliability bugs due to undefined behavior? Love the username, by the way :)

You can see some of the tooling they're using, .azure outlines CI & /tools has scripts like https://github.com/microsoft/msquic/blob/6fa51a42f69c59748dd...

There'll also be static analysis being thrown at it

Re: MsQuic – QUIC Implementation from Microsoft

#20

Post by slowstart »

modeless wrote: post #13

The feature I most want in a new network protocol is multipath to enable seamless and automatic connection migration between wifi and cellular. I haven't been following QUIC standardization, is that feature in now or postponed to the future?

Connection migration is part of the current Internet-Drafts. The generalized support for multi-path (i.e. usage of more than one path at the same time) is postponed to a future version of the protocol. You can follow the standards work here: https://quicwg.org/
Post reply on HN