-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding tcp-brutal Support to Xray, for [VLESS-gRPC-uTLS-REALITY + tcp-brutal] #2735
Comments
You need SetsockoptString after server accept tcp conn, means you need setsockopt on each transport type. |
Thank you for pointing out the crucial issue. I made a very basic mistake, and I need to rewrite all the code to achieve the goal. Sadly, I'm not familiar with the architecture of xray at all. Do you have any insights? 😢 |
I give up writing code in each transport hub.go, but set brutal module param in sockopt_linux.go, check the closed brutal pr, and xray commit, the only problem is required root permission. If you want get the worked code of transport/grpc hub.go, just check hysteria telegram group the tech discussion 1 weeks ago. |
Thank you very much! I believe our use cases align, and I will proceed with your proposed solution. |
I am endeavoring to add server-side support for tcp-brutal to xray-core, but I've encountered an issue that eludes resolution.
Let me provide some context and detail my objectives:
tcp-brutal is the congestion control algorithm from hysteria2, affording any protocol some of hysteria2's advantages. Its usage necessitates three conditions: the installation of a Linux kernel module, utilization exclusively on a protocol with multiplexing employing a single connection, and active algorithm specification with rate configuration by the application.
Key Point: Since downstream traffic dominates in most scenarios, enabling brutal on the server side yields immediate and impactful performance gains, without the need for client adaptation.
Naturally, my first inclination was toward "VLESS-gRPC-uTLS-REALITY + tcp-brutal" Consider the exquisite synergy: reality for obfuscation, grpc for multiplexing and low latency, vless for lightweight simplicity, and tcp-brutal (hysteria) for bandwidth enhancement.
I promptly experimented with the "VLESS-gRPC-uTLS-REALITY + brutal" combination, and it proved not only feasible but remarkably effective. Consequently, I crafted this code(#2734), aspiring to bring this exciting solution to the community. (For a quick validation, I directly edited the tcp-brutal source code to set the desired rate for personal use. In practical scenarios, using setsockopt as instructed in the tcp-brutal repository is essential, and this is where I encountered the issue.)
Herein lies the challenge: encountering an error when invoking the syscall.Setsockopt interface. Despite adding prints in the brutal kernel module, I cannot observe any output, suggesting that this system call doesn't enter the brutal code.
Lacking familiarity with setsockopt and Go, I seek the community's assistance in diagnosing this issue.
Testing Approach:
Follow the tcp-brutal instructions to install the brutal module. Then, create a simple configuration, adding the following to the inbound
(Please note that I've only provided configurations related to sockopt here. In actual usage, configurations for gRPC are also necessary. However, if it's solely for reproducing my issue, adding these is sufficient.)
This should result in an error: "failed to set brutal config, protocol not supported."
Summarizing my issue: Why did the setsockopt operation fail?
My current progress: I compared the Python sample program for tcp-brutal (https:/apernet/tcp-brutal/blob/bbd040546d697bddddb0a0760df76a781edef1b4/example/server.py#L20), and the structure of the configuration should be consistent. As mentioned earlier, I attempted to add prints in the brutal module, but no prints were observed when setsockopt was called.
For the configuration details of tcp-brutal, you can refer to this link: https:/apernet/tcp-brutal#for-developers
The above content was translated using a translator, so I'm not entirely sure if there are any errors. Please clarify if you have any questions.
The text was updated successfully, but these errors were encountered: