Has the project been stopped? It hasn't been renewed for a year. Why?

[InJoins]

From last June to this June, a year, no update, why?

Is it because there a design flaw?

Is it because the future expectations are different from those of .NET CORE?

Is the project abandoned or what is the ROADMAP of the future?

I look forward to your continuing this project, as you have already written the basic framework design.

please!🌹

[AlgorithmsAreCool]

I was under the impression that this project was a wild experiment by @Drawaes and @benaadams and was not ever really intended for production.

[InJoins]

After two days trying to continue this project, I think I've find out three possible reasons why this project has been stopped:

1. No open source implementation of TCP STACK based on C# can be found on the Internet, and it is too difficult to re-implement a robust and complete TCP STACK with C# following all standards;

The existing TCP implementation in this code base is just an experiment. If it needs to be productized in a real sense, I think it can't be easily done by two people, and the workload will be very large.

For example: I initially fixed a BUG in TCP OPTIONS resolution, but when I stress tested it, a new problem arose.
As for TCP OPTIONS alone, TcpOptionKind.Sack was not implemented.
When I looked at the standard, I found that it would take a lot of work to implement this almost necessary option.

2, The installation of NETMAP/DPDK is not an easy thing, requires users to manually install according to different system environment, and relatively tedious.
This is not a good fit for a cross-platform, one-click install of .NET CORE.
This part can let the user that pursues extreme performance realize by oneself, expand better.

3. The implementation of TCP protocol is almost all about byte calculation and operation.
   The efficiency of TCP STACK implemented with C# may not be as high as that of C language, which will offset the performance improvement brought by NETMAP/DPDK, so that the performance of the whole project will not improve too much.

If there is time and possibility, I think, it is possible to directly use C language to implement TCP protocol stack, and connect with NETMAP/DPDK, then export the higher level interface to C# to use directly, it may be more simple from the efficiency and implementation.

The C/GO/RUST community has implemented the NETMAP/DPDK plus a TCP STACK, and hopefully the .NET CORE community will implement the C# version.

BTW-1: I looked at all the commits in this repository from May to June.
Start from scratch, the authors wrote really quickly and I learned a lot.

BTW-2: I also tried Ben's Register IO for windows, benchmarks result is not very good when in a scenario that >100K concurrent connections.

BTW-3:I also tried .NET CORE 3.X's sockets with SAEA, slower than just using epoll on linux.

In summary, I'll stick on AspNetCore, is stable and richer and relatively fast when in a very high concurrent connections scenario.
Or, I'll implement/waiting for a NETMAP/DPDK/TCP implemention with C and then wrapped/port to C# directly.

Thanks.

[Drawaes]

The problem with implementation in c and then calling the higher API is you pay the interop call. It would be possible to do a stack but you would need more than two people, I agree the main sticking point was the install and testing of netmap on say a cloud server. If you could get it working on azure and find some helpers I would be back in ;)

[InJoins]

The problem with implementation in c and then calling the higher API is you pay the interop call.

Can I get rid of interop call if I let TCP STREAM MMAP to C# space, just like MAGMA did now?

It would be possible to do a stack but you would need more than two people,

If you come back, what about the C# version of TCP STACK?
It feels like a lot of work and not enough hands.

I agree the main sticking point was the install and testing of netmap on say a cloud server. If you could get it working on azure and find some helpers I would be back in ;)

I know little about azure. According to my preliminary understanding of netmap, it is not very compatible with cloud server system.
For example, I can only installed netmap successfully on ubuntu server in cloud enviroment.
And the compilation of its underlying network card driver must require the user to download the system kernel code.
This is not an easy and clean thing to do, but I really hope you can continue this project, so do you have any specific requirements in detail? Let the community know.

Thank you.

[InJoins]

After some investigation, why not just use freebsd's tcp stack?

Arch:
ethX <-> netmap(c) <-> freebsd's tcp stack(c) <->(a very fast/optimized queue of tcp packets/streamed data or a shared memory region or something else)<->DuplexPipe(c#)<->ManmaTransport(c#)<->MagmaTransportFactory(c#)<->WebHostBuilder.UseMagma(c# AspNetCore)

Need to comfirm:

1. freebsd is bsd license
   ok

2. the whole freebsd tcp stack's code is very clean, just need little modify and glue code
   I checked/compared every lines of libuinet's modify version of freebsd's tcp stack
   it's ok

3. freebsd tcp stack is production ready
   ok

4. tcp packets/streamed data from c layer to c# layer
   a shared memory region between c and c# space that wrapped with a very optimized queue algorithm
   in this part, I don't sure now, need more investigation about performance loss in this step
   not comfirmed.

@Drawaes
I am new to this area, not professional, could you talk something to me about this?
Thanks.

[a-tsymbal]

Maybe ixy project can be used to replace NETMAP/DPDK? There is a C# version ixy-languages/ixy.cs.

[AlgorithmsAreCool]

@a-tsymbal
The ixy stuff "works" but was done for a research project so it probably isn't super reliable. It was a pretty neat paper though.