What’s the added value of this fork?

[GyulyVGC]

Hi @ssrlive
First of all, thank you very much for maintaining this fork: I'm using the original repo and unfortunately noticed that it's no longer frequently updated and that issues and PRs are not considered much.

I wanted to ask you if this is just a maintained version, in the sense that you are willing to fix it / keep an active conversation with the community, or if this fork also adds notable features that are not present in the main repo.

If affirmative, I'd like to know what are such features so that I can decide whether to migrate to this fork.

Thanks for your time!

[ssrlive]

The biggest advantage of this fork is that it will continue to be maintained unless I die. The biggest modification of this fork so far is to hide packet information under the underlying logic and give end users a consistent interface. Of course, I also welcome you to join in the maintenance of this repo.

[GyulyVGC]

Thanks for the answer!

I was wondering if there was any plan to support proper multi-queue access to the device, since it can be a bottleneck to only write packets to a single queue.

In the original repo, the device can be split into a ReadHalf and a WriteHalf, which is good, but it'd be even better to be able to split it into different read/write queues, I think.

[ssrlive]

There is no plan for this, because our goal is to be compatible with as many platforms as possible, and some platforms such as Andriod / iOS / Windows do not support multiple queues, so we removed this logic from the original repo.