* maxUploadSize -> scMaxEachPostBytes, default is 1MB on both sides (was 2MB on the server)
* minUploadIntervalMs -> scMinPostsIntervalMs, default is 30ms on the client (no server support for now)
* maxConcurrentUploads -> scMaxConcurrentPosts, default is 100 on both sides (was 200 on the server)
Testing was conducted only using explicit parameters, and using
testsuite. However, when the parameters are not explicitly set in JSON
config, it seems that `c.MaxUploadSize` will contain `RandRangeConfig {
From: 0, To: 0 }` instead of `nil`, which breaks upload entirely.
* maxUploadSize and maxConcurrentUploads can now be ranges on the client
* maxUploadSize is now enforced on the server
* the default of maxUploadSize is 2MB on the server, and 1MB on the client
* the default of maxConcurrentUploads is 200 on the server, and 100 on the client
* ranges on the server are treated as a single number. if server is configured as `"1-2"`, server will enforce `2`
* querystrings in `path` are now handled correctly
When Close and Push are called concurrently, it may happen that Push attempts to write to an already-closed channel, and trigger a panic.
From a user perspective, it results in logs like this:
http: panic serving 172.19.0.6:50476: send on closed channel
It's probably triggered when download is closed at the same time an upload packet is submitted.
These panics don't crash the server and the inbound is still usable.
Fix#3566
Also update testsuite so that all tests read and write some data. Opening a connection is not enough to trigger connection errors, because the connection is so lazy.
* Refactor log
* Add new log methods
* Fix logger test
* Change all logging code
* Clean up pathObj
* Rebase to latest main
* Remove invoking method name after the dot
* Add H2C support to server
* update comment
* Make http1.1 ALPN work on SplitHTTP client
Users that encounter protocol version issues will likely try to set the
ALPN explicitly. In that case we should simply grant their wish, because
the intent is obvious.
* drain buffer correctly in httpupgrade
it seems the recently added httupgrade testsuite is causing timeouts on master
i have no evidence this is the real issue, but it feels to me that the
server could accidentally over-read, and then the encapsulated
connection will block forever trying to read data
let's test it in CI a couple of times, i don't have a way to reproduce
the issue
* correctly drain buffer, again
* preserve exact header casing when using httpupgrade
* fix capitalization of websocket
* oops, we dont need net/url either
* restore old codepath when there are no headers
v.conn.link.Reader is a pipe.Reader, doesn't implement Close(), it will fail assertion and cause the pipe to be left open
It can be fixed by using Interrupt()
* Add session context outbounds as slice
slice is needed for dialer proxy where two outbounds work on top of each other
There are two sets of target addr for example
It also enable Xtls to correctly do splice copy by checking both outbounds are ready to do direct copy
* Fill outbound tag info
* Splice now checks capalibility from all outbounds
* Fix unit tests
* chore: fix some errors detected by staticcheck
* feat: remove `rand.Seed()` usage for possibly using "fastrand64" runtime to avoid locking
ref: https://pkg.go.dev/math/rand#Seed
* 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>
Android client prepares an IP before proxy connection is established. It is useful when connecting to wireguard (or quic) outbound with domain address. E.g. engage.cloudflareclient.com:2408
* allow set interface under windows
Signed-off-by: San Zhang <zhangan@mail.com>
* polish code
Signed-off-by: San Zhang <zhangan@mail.com>
---------
Signed-off-by: San Zhang <zhangan@mail.com>
Co-authored-by: San Zhang <zhangan@mail.com>
Issue #2605 brought up real problem that QUIC dialer doesn't support sockopt at the moment. Inside `internet.DialSystem(...)` function, one of the branch that involves `redirect(...)` returns `cnc.connection` instance that is currently unhandled by the code logic, and thus caused program panic during runtime.
It seems the sockopt support for QUIC protocol requires a couple changes including making `cnc.connection` public, such that we can handle in dialer, along with some thorough tests, this commit simply adds safety check to explicity state the fact that QUIC isn't working with sockopt. And the implementation of the feature can be scheduled later on.
* Added tcp fragmentation for freedom outbound
* Added TCP_NODELAY to outbound sockopt
* Changed fragment parameters to accept ranges and changed strategy to use length
* Changed packetNumber to packets, supporting range.
* Refactored the freedom fragment logic
* Refine Write()
---------
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
