Feeds

back to article MS brandishes 'Katana' HTTP/2.0 server

Microsoft has gone public with a prototype HTTP/2.0 server. The server is designed to implement the version 4 HTTP/2.0 implementable draft published by the IETF earlier in July. The idea, according to IETF HTTPBIS chair Mark Nottingham, is that progressive implementations of HTTP/2.0 will feed back into the standard. “We're …

COMMENTS

This topic is closed for new posts.

Wait, what? Katana itself is hosted on CodePlex, Microsoft's own open source code repository, but they're choosing to host their fork on GitHub? *scratches his head*

Furthermore, I find it somewhat ironic that they're implementing a protocol designed to reduce application layer latency in a daemon written in a language that compiles to CIL bytecode, which must be run in a .NET virtual machine rather than natively.

3
8
Anonymous Coward

Umm. You do know that in this context, application layer latency refers to the client-server exchange over the network don't you ?

4
1

Yes, I most certainly do. I can see how it could be faster than HTTP/1.1, but I would expect that it would be even faster if it were compiled to native code. It is entirely possible that it's more than fast enough, but the VM still introduces overhead that doesn't exist on a native platform.

1
4
Anonymous Coward

The network latency will overwhelm any possible gain from switching to native code. In other words, it won't make a difference worth a damn.

7
1
Windows

C# runs fully compiled

That MSIL somehow runs interpreted is a common misunderstanding. When a C# program executes it executes fully compiled.

C# is compiled *ahead* of execution, in principle on a method-by-method basis (in reality multiple classes are compiled at once). When a method has been executed *once*, subsequent invocations simply run the compiled method.

MSIL was never intended to be an interpreted language. From the start it was designed to be compiled to the final representation on the target architecture. Because it is type-safe and statically typed, it also do not need the typical type checks that dynamic language suffer from.

9
2
LDS
Silver badge

Re: C# runs fully compiled

But it still runs within the .NET VM and is subject to its checks and workings. Sure, part of the code is turned into native opcodes, still it is different from a fully compiled native application which runs fully on the processor directly.

3
6
Bronze badge

Don't worry Jordan. I've rewritten it in assembler. Pull request is in place.

I just hope they don't change anything between now and November next year when it's due to be submitted as a standard. Then I'd regret not writing it in C#.

5
0

Re: C# runs fully compiled

But it still runs within the .NET VM and is subject to its checks and workings.

There is no such thing as a .NET VM.

There is the common language runtime (CLR) which (as the name hints) is more of a library and initialization code. There is no "virtual machine" that interprets byte codes.

You can host the CLR in your own process (.NET is actually a COM "server"), although the compilation is performed by a JIT compilation service.

When you ask the CLR to run a .NET executable, you ask the CLR to load the assembly, use reflection to find the entry method and ask CLR to execute that method. At that time the CLR will compile the method from the MSIL code of the assembly (or take it from the cache if it has already been compiled) and invoke the compiled code. If the method invokes other methods, the method may be a compilation stub which compiled the method and replaces the reference to the stub with a pointer to the compiled method. Subsequent invocations will thus directly invoke the already compiled method.

.NET code (at least on the Windows platforms) execute fully compiled.

Sure, part of the code is turned into native opcodes, still it is different from a fully compiled native application which runs fully on the processor directly.

No, all of the code is turned into native instructions. All of it. It may not happen until just before the method is executed, but all of the code that is eventually executed is compiled code.

The difference from fully compiled native code is that the compiled code is obtained dynamically from a compiler (or cache) on the target platform, i.e. applications are distributed as MSIL and depends on the MSIL compiler service being available at the target computer.

There is even a tool (ngen.exe) that will pre-populate the cache with *all* of your application code compiled into native code, alleviating the need for JIT compilation.

You may want to read this: http://msdn.microsoft.com/en-us/library/9x0wh2z3(v=vs.90).aspx

3
1

Re: The network latency will overwhelm any possible gain

True.. to some extent.

The early HTTP servers were written in Perl. A language that is utterly slower than "native" code, for almost anything related to an network service. That made some sense at the time, when the prevalent connectivity was up to 9600 bps dial-up.

Not much later, the most popular web server, Apache was written in C.

Anyway, for a prototyping task, implementing a new protocol in any language is ok. For demonstrating that it is "better" to the non-scientific community however, this approach is an very bad idea.

0
0
IT Angle

Re: C# runs fully compiled

>When a method has been executed *once*, subsequent invocations simply run the compiled method.

And then if you modify the source, it is recompiled AT RUNTIME, which is essentially INTERPRETTING. Doesn't matter how many new names MS come up with for the multitude of layers that exist between reading the instructions and executing them on the metal.

.NET is basically a 'compiled' most of the time, 'interpretted'/'recompiled' when modified, execution model.

Kids these days...etc

I remember... having to bend paper clips to flip bits... arg!

0
2
Silver badge
FAIL

Re: C# runs fully compiled

And then if you modify the source, it is recompiled AT RUNTIME, which is essentially INTERPRETTING

Yes. Once. And then it runs fully compiled.

However, distributed binaries cannot be modified without trashing them anyway so any new souce modification comes from the developer and is then distributed and runs, er compiled.

You dick.

0
0
Flame

Re: C# runs fully compiled

>You dick.

Take that back and I might enter into reasonable discourse with you.

Otherwise you are a cunt.

0
1
Silver badge

Re: C# runs fully compiled

Why should I? If you're going to spread FUD about languages being interpreted or otherwise, what use are you?

1
0
Holmes

Re: C# runs fully compiled

The answers you seek lie within...(the questions you ask)

0
0
Silver badge

Katana?

Will it be called the Dreamcast server on release?

1
0
LDS
Silver badge

Interesting... after years of text-based protocols we're back to binary ones...

This protocol is interesting because after years of text-based protocols and data exchange formats someone understood they were not the most efficient, and designed a binary one...

1
3

Re: Interesting... after years of text-based protocols we're back to binary ones...

SPDY really is just compression and multiplexing the HTTP part does not change. Saying http/2.0 is a binary protocol is like saying http1 is binary when you send it over ssl.

1
0

This post has been deleted by its author

Bronze badge

Whether or not C# is really compiled or not, to the people who are saying a bytecode web server wouldnt matter due to network latency...have you ever heard of system resources required to perform a given action? Which is inevitably higher with a language not fully compiled. Given this, you could say that it will impact performance because everyone has a budget of some description and hence the limit at which requests can be serviced in a timely manner will be reached quicker and provide a slower response time at this given tipping point, the tipping point arriving sooner in a bytecode server with the same system resources.

4
4
Bronze badge
Trollface

They want fast?

How about FastCGI? You can even run it with IIS - Link to www.iis.net

Oh, sorry no, that won't happen - You would need people who know how to code...

And you try and tell the young people of today that... they won't believe you. (Four Yorkshiremen).

0
3

Daaayyyuuuum! My native HTML5 appz will be running sooo faasst on this shit! Woooo!! Scale to the cloud baby!

0
1
Bronze badge
Joke

Lols

"Microsoft" and "HTTP server" in the same sentence? You guys!

Being serious for a second though, I hope the working group are sensible about what will be fed back into the specs from this implementation. Though maybe it needs a bit of balance since at the moment it seems like Google are driving it forward with SPDY.

1
3

Does anyone know whether it will support SCTP (http://en.wikipedia.org/wiki/SCTP) transport in addition to TCP? SCTP is a protocol at the level of TCP or UDP which is intended for just this sort of message stream. It's extensively used in the telecoms world for signalling, but is not supported on Windows without a 3rd party driver.

2
0

I can't imagine them deciding to explicitly name SCTP in the spec - but I don't see a reason why HTTP/2.0 servers couldn't function using the "withsctp" wrapper script available for various Linux distributions.

1
0
Silver badge

.Net of course

That way they can be sure their reference implementation only runs worth a damn on windows. You didn't think they were going to truly write cross platform code for the world to use did you? (and mention Mono and I will laugh at you, with Mono you are lucky if your code runs right, forget performance)

1
1
Megaphone

Re: .Net of course

Mono. Mono. Mono!

It is not intended to be a production server. It makes perfect sense to implement a PoC using a language which has a high productivity (using e.g. LINQ and - probably more relevant in this case - async/await asynchronous methods) combined with a good performance.

Async/await makes creating asynchronous methods (much) easier while still have the methods resemble the logical flow of the application.

1
0
Silver badge

Re: .Net of course

There are other technologies that allow true cross platform RAD but from a business perspective what Microsoft did was perfectly reasonable especially as you mention for a PoC.

0
0
This topic is closed for new posts.