折腾了一天，简单的例子都跑不起来。程序是编译成功了，对跨语言开发者其实是非常不友好的。但是需求大家是很清楚的。应该有一个简单的上传与下载文件的DEMO，就比较方便了。能得到第一时间上的直观反应。

Reference：

• https://datatracker.ietf.org/doc/html/rfc9000#name-path-maximum-transmission-u
• https://datatracker.ietf.org/doc/html/rfc1191
• https://datatracker.ietf.org/doc/html/rfc8201

Reference

• https://datatracker.ietf.org/doc/html/rfc9000#name-deferring-idle-timeout
• https://datatracker.ietf.org/doc/html/rfc9308#name-connection-termination

Reference：
https://mozilla.github.io/uniffi-rs/

Hi!

Recently I did many Profile-Guided Optimization (PGO) benchmarks on multiple projects - the results are available here. I think since the project is performance-oriented, it would be interesting to try to test PGO for optimizing tquic. I already did some benchmarks.

Test environment

• Fedora 38
• Linux kernel 6.5.5
• AMD Ryzen 9 5900x
• 48 Gib RAM
• SSD Samsung 980 Pro 2 Tib
• Compiler - Rustc 1.73
• tquic version: the latest for now from the develop branch on commit 05c56e7425ec1149a9c95ca7bbcb6acbab861fd6
• Disabled Turbo boost

Benchmark setup

For benchmarking purposes, I use the project's benchmarks. Release benchmarking is done with cargo bench, PGO optimized build is done with cargo-pgo with cargo pgo bench && cargo pgo optimize bench. PGO profiles are collected from the benchmark workload itself.

Results

I got the following results:

• Release + PGO-optimized compared to Release: https://gist.github.com/zamazan4ik/875e3d1948ac3db575bcbb442a6f6ebb
• (just for reference) PGO-Instrumented compared to Release: https://gist.github.com/zamazan4ik/f4af4f2e510d433253bf007ecb584507

According to the tests, PGO consistently improves tquic performance in some scenarios.

Further steps

I can suggest the following things to do:

• Evaluate PGO's applicability to tquic in more scenarios.
• If PGO helps to achieve better performance - add a note to tquic's documentation about that (probably somewhere in the README file). In this case, users and maintainers will be aware of another optimization opportunity for tquic.
• Maybe get some insights from the PGO profiles and optimize manually the code according to the profiles (maybe more aggressive inlining or something like that)

Reference

• https://datatracker.ietf.org/doc/html/rfc9000#name-explicit-congestion-notific

Reference:

• https://github.com/Tencent/tquic/blob/develop/interop/run_endpoint.sh

• Support high-level async API based on tokio

Reference

• https://tokio.rs/tokio/tutorial
• https://github.com/hyperium/h3/blob/master/docs/PROPOSAL.md#5-quic-transport

Describe the solution you'd like
Webtransport based on tquic.

I am just curious if you plan to add tquic to the https://github.com/quic-interop/quic-interop-runner

as described here: https://github.com/quic-interop/quic-interop-runner/blob/master/README.md#building-a-quic-endpoint

I see you have written an interop Dockerfile, etc. - https://github.com/Tencent/tquic/tree/develop/interop

Thanks for creating tquic

#41

Reference

• https://www.rfc-editor.org/rfc/rfc9287.html

Change "IPv4Addr" to "IPv6Addr" in the comments.

Reference:

• https://github.com/Tencent/tquic/blob/develop/.github/workflows/rust.yml

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Reference：
https://mozilla.github.io/uniffi-rs/

Reference

• https://datatracker.ietf.org/doc/html/rfc9204#name-dynamic-table

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Reference

• https://datatracker.ietf.org/doc/html/rfc9114
• https://datatracker.ietf.org/doc/html/rfc9204

• Add --method METHOD option to specify the HTTP request method
• Add --body FILE option to specify the HTTP request body
• Add support for sending requests in 0RTT packets
• Add support for mutual authentication

I am currently looking at alternatives for quinn, but due to my current usage, I am relying on rustls for TLS handling (platform support, and custom certificate verification). So I was wondering if you are open to enabling different TLS backends. Either in a fully generic form, or by feature flagging boringssl & rustls.

Describe the bug

When multiple streams coexist and incremental flag is set to true, the server uses round-robin to schedule the sending of streams.
In tquic, it runs as follow:
When sending a packet, connection will call try_write_stream_frames(...) to populate stream frame to given packet payload buffer. And it use round-robin to decide which frame's data should be loaded into the packet buffer. However, the problem is: when enough data is written to the payload buffer for the first scheduled stream, the round-robin scheduling will not exit immediately but will continue to execute. When the second one is scheduled, it will check whether there is enough buffer, and if not, it will be exited. But at this point, round-robin has already put the stream to the end of the scheduling queue, even if it doesn't successfully send a single byte of data.

In this case, I observed in my own experiment that when I have two long streams at the same time, one stream is always in a state of starvation, because every time a packet is about to be sent, the other stream has already used up the payload buffer, but the stream is put back to the end of the scheduling queue by round-robin without sending any data, and the cycle repeats.

So I'm wondering if we should put a stream at the head of the queue instead of the end of the queue when it's not actually successfully sending data, so that it can be dispatched the next time a packet is about to send out.

Relative codes:
https://github.com/Tencent/tquic/blob/develop/src/connection/connection.rs#L2189-L2259
https://github.com/Tencent/tquic/blob/develop/src/connection/stream.rs#L704-L732

Thanks, and best regards.

我在对tquic_client进行测试时发现，即使设置了max_requests_per_conn这一参数，每个conn发送的请求数量依旧被限制在1000，这个上限是tquic_client设置的吗？还是tquic本身的限制？能否更改呢

fn on_packets_send(&self, pkts: &[(Vec<u8>, PacketInfo)]) -> tquic::Result<usize> {}

建议将 Vec<u8>类型改为 bytes::Bytes类型；这样应用层在处理时可以减少内存的copy

怎么和nginx在一起配置使用

Reference

• https://datatracker.ietf.org/doc/html/rfc8879

Reference

• https://datatracker.ietf.org/doc/html/rfc9221

Describe the bug
Linux(Ubuntu) 下 relase/v0.5.0 安装时出现的问题：error: failed to select a version for the requirement tquic = "^0.4.0"``

To Reproduce
将./tquic-0.5.0/tools/Cargo.toml中的
tquic = { path = "..", version = "0.4.0"} 为 tquic = { path = "..", version = "0.5.0"}

Expected behavior
修改完可以 build 了

想使用自组网电台实现点对点的视频传输，解决弱网环境下的视频传输问题。
是否有相关的测试用例可以参考：比如，前端通过无线摄像头模块采集数据，摄像头借助自组网电台构建的通道，将数据实时传输到后端；具体如何实现呢？能否有可参考的案例用起来呀。

timer_heap only used in test case, move it into dev-dependencies

实际测试中，当 done 为0时，之后就再也没有重试发送

When building in a windows environment I encountered the following issues.

1. cant find ssl and crypto libraries

   Compiling tquic v0.2.0 (E:\Docs\devw\2023\tquic)
error: could not find native static library `ssl`, perhaps an -L flag is missing?

error: could not compile `tquic` (lib) due to previous error

Looks like the libraries are stored under the out/build/Debug folder not out/build. Can be fixed by adding this folder in build.rs.

    Directory: E:\Docs\devw\2023\tquic\target\debug\build\tquic-959af7c8517dba55\out\build\Debug


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        11/20/2023  10:31 PM        5014178 crypto.lib
-a----        11/20/2023  10:33 PM        1619950 ssl.lib

2. tikv-jemallocator wont compile

[ERROR rust_analyzer::main_loop] FetchBuildDataError:
The following warnings were emitted during compilation:


error: failed to run custom build command for `tikv-jemalloc-sys v0.5.4+5.3.0-patched`
note: To improve backtraces for build dependencies, set the CARGO_PROFILE_DEV_BUILD_OVERRIDE_DEBUG=true environment variable to enable debug information generation.

Caused by:
  process didn't exit successfully: `E:\Docs\devw\2023\tquic\target\debug\build\tikv-jemalloc-sys-eafeea802f535c08\build-script-build` (exit code: 101)
  --- stdout
  TARGET=x86_64-pc-windows-msvc
  HOST=x86_64-pc-windows-msvc
  NUM_JOBS=12
  OUT_DIR="E:\\Docs\\devw\\2023\\tquic\\target\\debug\\build\\tikv-jemalloc-sys-abde19670416cf39\\out"
  BUILD_DIR="E:\\Docs\\devw\\2023\\tquic\\target\\debug\\build\\tikv-jemalloc-sys-abde19670416cf39\\out\\build"
  SRC_DIR="C:\\Users\\ant\\scoop\\persist\\rustup-msvc\\.cargo\\registry\\src\\index.crates.io-6f17d22bba15001f\\tikv-jemalloc-sys-0.5.4+5.3.0-patched"
  cargo:warning="jemalloc support for `x86_64-pc-windows-msvc` is untested"
  cargo:rustc-cfg=prefixed
  cargo:rerun-if-env-changed=JEMALLOC_OVERRIDE
  OPT_LEVEL = Some("0")
  TARGET = Some("x86_64-pc-windows-msvc")
  HOST = Some("x86_64-pc-windows-msvc")
  cargo:rerun-if-env-changed=CC_x86_64-pc-windows-msvc
  CC_x86_64-pc-windows-msvc = None
  cargo:rerun-if-env-changed=CC_x86_64_pc_windows_msvc
  CC_x86_64_pc_windows_msvc = None
  cargo:rerun-if-env-changed=HOST_CC
  HOST_CC = None
  cargo:rerun-if-env-changed=CC
  CC = None
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
  DEBUG = Some("true")
  cargo:rerun-if-env-changed=CFLAGS_x86_64-pc-windows-msvc
  CFLAGS_x86_64-pc-windows-msvc = None
  cargo:rerun-if-env-changed=CFLAGS_x86_64_pc_windows_msvc
  CFLAGS_x86_64_pc_windows_msvc = None
  cargo:rerun-if-env-changed=HOST_CFLAGS
  HOST_CFLAGS = None
  cargo:rerun-if-env-changed=CFLAGS
  CFLAGS = None
  CC="C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\VC\\Tools\\MSVC\\14.37.32822\\bin\\HostX64\\x64\\cl.exe"
  CFLAGS="-nologo -MD -Z7 -Brepro -W4"
  JEMALLOC_REPO_DIR="jemalloc"
  cargo:rerun-if-env-changed=JEMALLOC_SYS_WITH_MALLOC_CONF
  cargo:rerun-if-env-changed=JEMALLOC_SYS_WITH_LG_PAGE
  cargo:rerun-if-env-changed=JEMALLOC_SYS_WITH_LG_HUGEPAGE
  cargo:rerun-if-env-changed=JEMALLOC_SYS_WITH_LG_QUANTUM
  cargo:rerun-if-env-changed=JEMALLOC_SYS_WITH_LG_VADDR
  --with-jemalloc-prefix=_rjem_
  running: "sh" "E:/Docs/devw/2023/tquic/target/debug/build/tikv-jemalloc-sys-abde19670416cf39/out/build/configure" "--disable-cxx" "--enable-doc=no" "--enable-shared=no" "--with-jemalloc-prefix=_rjem_" "--with-private-namespace=_rjem_" "--host=x86_64-pc-win32" "--build=x86_64-pc-win32" "--prefix=E:\\Docs\\devw\\2023\\tquic\\target\\debug\\build\\tikv-jemalloc-sys-abde19670416cf39\\out"
  checking for xsltproc... false
  checking for x86_64-pc-win32-gcc... C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.37.32822\bin\HostX64\x64\cl.exe
  checking whether the C compiler works... no
  running: "tail" "-n" "100" "E:\\Docs\\devw\\2023\\tquic\\target\\debug\\build\\tikv-jemalloc-sys-abde19670416cf39\\out\\build\\config.log"

  --- stderr
  configure: error: in `/e/Docs/devw/2023/tquic/target/debug/build/tikv-jemalloc-sys-abde19670416cf39/out/build':
  configure: error: C compiler cannot create executables
  See `config.log' for more details
  thread 'main' panicked at C:\Users\ant\scoop\persist\rustup-msvc\.cargo\registry\src\index.crates.io-6f17d22bba15001f\tikv-jemalloc-sys-0.5.4+5.3.0-patched\build.rs:347:19:
  failed to execute command: program not found
  stack backtrace:
     0: std::panicking::begin_panic_handler
               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library\std\src\panicking.rs:595
     1: core::panicking::panic_fmt
               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library\core\src\panicking.rs:67
     2: build_script_build::main::{{closure}}
     3: build_script_build::main::{{closure}}
     4: build_script_build::main::{{closure}}
     5: build_script_build::main::{{closure}}
     6: build_script_build::main::{{closure}}
     7: <core::str::pattern::CharSearcher as core::str::pattern::Searcher>::haystack
     8: core::fmt::Arguments::new_const
     9: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
    10: std::rt::lang_start
    11: std::rt::lang_start_internal::closure$2
               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library\std\src\rt.rs:148
    12: std::panicking::try::do_call
               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library\std\src\panicking.rs:502
    13: std::panicking::try
               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library\std\src\panicking.rs:466
    14: std::panic::catch_unwind
               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library\std\src\panic.rs:142
    15: std::rt::lang_start_internal
               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library\std\src\rt.rs:148
    16: std::rt::lang_start
    17: main
    18: invoke_main
               at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
    19: __scrt_common_main_seh
               at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
    20: BaseThreadInitThunk
    21: RtlUserThreadStart
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

as a workaround this library can be disabled for windows

你好，有多线程服务端的压测数据吗
想测试下 多线程情况下， server 持续发送数据1Mb/s 给客户端， 看看这种场景下的性能
背景是 评估直播场景下 这个库的性能怎么样

Add the following wrapped APIs based on stream_new

• stream_bidi_new

pub fn stream_bidi_new(
    &mut self,
    urgency: u8,
    incremental: bool
) -> Result<u64>

• stream_uni_new

pub fn stream_uni_new(
    &mut self,
    urgency: u8,
    incremental: bool
) -> Result<u64>

Reference

• https://datatracker.ietf.org/doc/rfc9369/

Add more example , for example: h3 request etc.

建立连接成功能，如何让会话自动保持