Support reading a string from a buffer till a delimiter from ReadableBuffer

[seertenedos]

I am working on a Nntp server/client that uses a /r/n command delimiter but really it could be any delimiter people want instead of a fixed string length. since you are wrapping a socket lib the chances are people will want it for some sort of protocol so some way to check the location of something in the buffer and to extract to that point would be great. I don't really want to manage a string buffer on top of our ReadableBuffer as it seems like a waste to double buffer.

[StormHub]

The internal buffer actually had this built in but not exposed. Let me have a look at it first.

[seertenedos]

Thanks.

On Fri, 2 Jun 2017 at 8:11 pm, Johnny Z notifications@github.com wrote:

The internal buffer actually had this built in but not exposed. Let me have a look at it first.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/StormHub/NetUV/issues/39#issuecomment-305746980, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYeca-9H-m8sjH2mEY2bMV7mCnhCrE1ks5r_9-9gaJpZM4NuBdj .

[StormHub]

Initially, the idea was to pull the entire buffer as a string and decrements the buffer ref.

[seertenedos]

In my case I am basically a pass though between multi client to multi server so want to minimise work I do. If I read out 1.5 commands then I need to store the 0.5 of a command till the rest comes in.

Even thought about reading pure binary but still have a similar issue of needing to read till a particular character or byte code so need to buffer the extra data for the complete next command.

On Fri, 2 Jun 2017 at 8:15 pm, Johnny Z notifications@github.com wrote:

Initially, the idea was to pull the entire buffer as a string and decrements the buffer ref.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/StormHub/NetUV/issues/39#issuecomment-305747836, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYecZCt0Zu0k-yMVJLFibJoZ3bmgj8Uks5r_-C7gaJpZM4NuBdj .

[StormHub]

I see.

[seertenedos]

basically i am aiming for over 80mbps thoughput. i could only get 80mbps using standard dotnet core sockets so i am hoping libuv and more efficient handling of the network level will help with performance

[StormHub]

I put libuv and netty buffer management together is pretty much aiming to achieve the same thing, very tight io spin with zero buffer copy :D

[seertenedos]

i could see that it seemed well done so that was why i was hoping it could be built into the buffer if possible.

[StormHub]

let me expose some sort of read until to the buffer.

[seertenedos]

just wanted to let you know converted my code over to your lib from normal coreclr TcpClient using async without converting my clients yet and instantly halved cpu usage and got 110mbps thoughput which is the max of my internet connection. great job on performance! The buffer request above will most likely help even further and i can't wait to see cpu usage once i convert my client code as well.

[StormHub]

Glad to hear! One of my motivations of this package was almost the same as what you have seen. Win sock async api does lots of context switching and buffer copying. I could not afford that for some heavy network tunnelling applications.

[StormHub]

PR merged.