port HTTP 1.1 codec

[zmyer]

en...,I have written some codes about HTTP/HTTP2.0, but it was not finished,which was according to Netty source code, ye...,there are so much codes needed to write, but I have finished about 80%, do you have interest in it or can you give me some help? Thanks

[nayato]

The biggest problem I found with porting HTTP codec is a CharSequence. There's no direct equivalent in .NET and there's no easy way to make one up (if only String implemented IReadOnlyList<char>..). It is an important issue because HTTP codec heavily relies on AsciiString which offers zero-copy implementation of CharSequence on top of byte buffer. Honestly, I haven't had time to evaluate possible solutions to that issue but it sure should not be "let's just use strings instead".

[zmyer]

yes, I find there are so much limits to implement HTTP/HTTP2.0 in DotNetty, and so no, I have finished it by using String, but now , my forcus is to run HTTP/HTTP2.0 in DotNetty only, because the project deadline is nearly...

[pandaGaume]

Guys, did you manage to finalize the Http port ??? I've just started to make it because of internal needs, but if already done, there is no more subject...

[nayato]

@pandaGaume my current progress is in https://github.com/nayato/DotNetty/tree/http. I'm currently busy with .NET Standard support and likely won't have time to work on HTTP further till next week.

[nayato]

@pandaGaume feel free to chat on gitter if you seriously want to take it.

[xiongtec]

Any update on adding HTTP?

[hstcscolor]

@nayato Do you have time to update https://github.com/nayato/DotNetty/tree/http ? I think this part is so important to use DoNetty in production environment.

[StormHub]

I'm trying to come up with a workable port first.

[ZigMeowNyan]

@nayato I'm not sure that the CharSequence problem you detailed is really that complex. The internal implementation of AsciiString in netty (4.1) is a byte[]. Only byte[] and ByteBuffer constructors offer the ability to reuse the value (byte/buffer) parameter, and the others all copy and convert the equivalent parameter into a byte[]. All zero-copy code in AsciiString seems based on direct byte access and comparisons. Functions that work with char seem to internally call b2c to convert the byte to a char - like the implementation of charAt for the CharSequence interface.

I might be misreading this, but it seems like no one should be scared off by zero-copy char concerns here. In fact, aiming for something that uses a char[] internally like a string would just complicate the forEachByte methods that process individual bytes with a ByteProcessor and pointlessly distance this port from the netty source.

I think you already got past this point, but we haven't heard anything, and it'd be a shame for needless difficulty to scare off anyone else interested in the issue. It's hard for people to pick up a branch with a single commit and no other information. And I'm worried the above warning about AsciiString might have scared possible implementors away from a fresh start, or from sharing what they've already started.

[StormHub]

@ZigMeowNyan Functionality wise is not that big of a deal, what @nayato meant was that in Java String/StringBuilder all implement ICharSequence, therefore, it is possible for http message processing to have zero-copy performance benefits. .NET is different, you have to keep substring /copy things around. It is by no means to 'scare' people off. I believe the intention is to highlight the performance implications.

[StormHub]

Original Netty heavily using ICharSequence for processing logic. Not that so straightforward and easy.

[StormHub]

@nayato BTW: I am almost done now, do you mind to have a look first (AsciiString to start) my http branch. just have a few things to sort out.

[ZigMeowNyan]

So the zero-copy implementation aspect is not so much in the AsciiString implementation, but instead in the other implementations of CharSequence that all the higher layers are using when calling functions? Good to know. I got started looking into this thinking a tiny string wrapper using C# 7 ref returns for the chars might be a viable implementation, but then got hung up on the

relies on AsciiString which offers zero-copy implementation of CharSequence

bit above which wasn't matching with what I was seeing when taken directly.

Thanks for clearing that bit up.

[StormHub]

@ZigMeowNyan NP, I have been trying quite a few ways so far, seems like I found a reasonable way to go ahead. Meanwhile, HTTP is not only http implementation itself, you have to deal with java IO/File API to .NET Stream, Gzip/Zlib etc. lots of fun challenges.

[SetoKaiba]

Any news on this yet?

[hstcscolor]

@SetoKaiba See https://github.com/Azure/DotNetty/pull/256