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 …
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.
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.
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.
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
>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!
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.
This post has been deleted by its author
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.
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).
"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.
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.
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)
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
