* v5: Health Check & LeastLoad Strategy (rebased from 2c5a71490368500a982018a74a6d519c7e121816)
Some changes will be necessary to integrate it into V2Ray
* Update proto
* parse duration conf with time.Parse()
* moving health ping to observatory as a standalone component
* moving health ping to observatory as a standalone component: auto generated file
* add initialization for health ping
* incorporate changes in router implementation
* support principle target output
* add v4 json support for BurstObservatory & fix balancer reference
* update API command
* remove cancelled API
* return zero length value when observer is not found
* remove duplicated targeted dispatch
* adjust test with updated structure
* bug fix for observer
* fix strategy selector
* fix strategy least load
* Fix ticker usage
ticker.Close does not close ticker.C
* feat: Replace default Health Ping URL to HTTPS (#1991)
* fix selectLeastLoad() returns wrong number of nodes (#2083)
* Test: fix leastload strategy unit test
* fix(router): panic caused by concurrent map read and write (#2678)
* Clean up code
---------
Co-authored-by: Jebbs <qjebbs@gmail.com>
Co-authored-by: Shelikhoo <xiaokangwang@outlook.com>
Co-authored-by: 世界 <i@sekai.icu>
Co-authored-by: Bernd Eichelberger <46166740+4-FLOSS-Free-Libre-Open-Source-Software@users.noreply.github.com>
Co-authored-by: 秋のかえで <autmaple@protonmail.com>
Co-authored-by: Rinka <kujourinka@gmail.com>
Xtls is magic, don't play with it ;)
A knowledged guess is the timing to switch to splice is very sensitive. Now both Xtls and Freedom outound do the switching when pipe just finished one buffer
It seems the root cause is if the flag set at the inbound pipe reader, it is a race condition and freedom outbound can possibly do splice at the same time with inbound xtls writer.
Now we set the flag at the earliest and always do splice at the next buffer cycle.
- Vision now use traffic states to capture two-way info about a connection
- XTLS is de-couple with Vision, it only read traffic states to switch to direct copy mode
- fix a edge case error when Vision unpadding read 5 command bytes
- Add outbound name
- Add outbound conn in ctx
- Refactor splice: it can be turn on from all inbounds and outbounds
- Refactor splice: Add splice copy to vless inbound
- Fix http error test
- Add freedom splice toggle via env var
- Populate outbound obj in context
- Use CanSpliceCopy to mark a connection
- Turn off splice by default
* Vision server allow multiple blocks of padding
* Fix Vision client to support multiple possible padding blocks
* Vision padding upgrade
- Now we have two types of padding: long (pad to 900-1400) and traditional (0-256)
- Long padding is applied to tls handshakes and first (empty) packet
- Traditional padding is applied to all beginning (7) packets of the connection (counted two-way)
- Since receiver changed its way to unpad buffer in fd6973b3c6, we can freely extend padding packet length easily in the future
- Simplify code
* Adjust receiver withinPaddingBuffers
Now default withinPaddingBuffers = true to give it a chance to do unpadding
* Fix magic numbers for Vision
Thanks @H1JK
Thanks @RPRX for guidance
This only affects the Vision client for protocols expecting server to send data first.
The change is compatible with existing version of Vision server.
In the past, when user open xtls vision on the server side, plain vless+tls can connect.
Pure tls is known to have certain tls in tls characters.
Now server need to specify "xtls-rprx-vision,none" for it be able usable on the same port.
Before this change, Vision client need a pure inbound like socks or http.
After this change, it will support any inbound.
This is useful in traffic forwarder use case inside China.
yuhan6665
RPRX
hax0r31337
Eken Chan
世界
Hellojack
MP