Yuwei Ba

i think we already have some level of gRPC support https://github.com/Watfaq/clash-rs/blob/c84d26251b9bb2e648a97f9e15accce903884b6c/clash_lib/src/proxy/transport/grpc.rs#L49 i had a quick look at `gun`, which seems to be something similar(same) to the grpc transport?

I'm setting up a grpc proxy to test it out. I don't think that code has been tested ever.

it looks `gun` is grpc over h2. i'm working on the PR #203 however there seems to be something wrong. i'll try to fix it later.

I'm kind of stuck - https://github.com/Watfaq/clash-rs/pull/203 if you are more familiar maybe you can take a look, or I'll get back when I have more time to dig in

the gun/gRPC is done. maybe we should promote this - however is this in general more popular/better then vmess?

https://github.com/shadowsocks/shadowsocks-rust/pull/1379 https://github.com/hickory-dns/hickory-dns/pull/2107

what are you exactly trying to do in your patch? could you add a description, what's the issue and why your change is useful?

have you checked the tokio implementation? https://docs.rs/tokio/latest/src/tokio/io/util/copy_bidirectional.rs.html#72-91 does it have the same issue that you are mentioning here? i think i still don't understand how your change is different, i...

~~i think this line is problematic - the await is block, and in the case the 2nd future is errored/finished before the 1st, it'd never know https://github.com/Watfaq/clash-rs/pull/206/files#diff-85611fef80536aedcb4665af1a4b566df2341c0e3b6cdf60b28eaf9a1d81ba92R433~~ this may not...

> When a future is wakened, the other future will be polled again even though it is not notified by its ctx.wake(). i think this is not a big issue...