-
Notifications
You must be signed in to change notification settings - Fork 548
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
SIP003u - UDP Extension for SIP003 Plugins #180
Comments
Related issues/discussionsMentionsShadowsocksQv2rayV2FlyXTLS |
Preliminary proposal by @studentmain:
|
Why not just add a flag in configuration? For example, |
- ref shadowsocks/shadowsocks-org#180 - "plugin_mode" option in configuration file, and ssmanager API - "plugin_mode" is "tcp_only" by default
- ref shadowsocks/shadowsocks-org#180 - "plugin_mode" option in configuration file, and ssmanager API - "plugin_mode" is "tcp_only" by default - ref #1127
- ref shadowsocks/shadowsocks-org#180 - "plugin_mode" option in configuration file, and ssmanager API - "plugin_mode" is "tcp_only" by default - ref #1127
The new Maybe we should reserve a special key in
So many caveats! We might as well start over and define new environment variables.
The life cycle section in the spec also needs some clarification. What signal to send to the plugin process? How long to wait before sending SIGKILL? What about Windows?
|
If a plugin supports SIP003u, it will only need to provide a UDP tunnel, the process steps would be: For the local plugin:
For the server plugin:
So the implementation would be quite simple, |
https://github.com/zonyitoo/shadowsocks-yamux-plugin |
I don't think plugins should know |
Fair enough. I guess you could open a PR to update the spec doc and then close this issue? |
It is still an experimental feature. Let's keep it open and see if there are any other comments. |
I used this feature with shadowsocks-yamux-plugin for more than a week, everything works perfect as expected. UDP (H3) felt more stable with UoT (supported by the shadowsocks-yamux-plugin) than direct UDP mode. |
I came here by searching why whatsapp call is not working as calls happen over UDP and the outgoing udp is blocked, then it won't work. any update on udp over tcp support? this comment sums it up. |
Does v2ray-plugin support UDP Extension ? I want something like v2ray-plugin work behind in nginx proxy but with UoT support. |
did you have any success? I tried with |
Refined proposal: SIP011: UDP Extension for SIP003 Plugins1. AbstractThe original proposal of SIP003 didn't include support for UDP. The lack of UDP support has significantly limited the possible use cases of SIP003. There are reports that shadowsocks UDP data flows are blocked or detected by malicious third-parties. By allowing Plugins to support transporting UDP, it will be possible to implement features like UDP obfuscation, UDP-over-TCP. 2. Implementation Requirements
Passing Arguments to a PluginArguments are exactly the same as SIP003. 3. Implementation Details3.1. Default BehaviorSIP011 is disabled by default in all shadowsocks implementations. Any plugins that support SIP011 should be able to run independently with implementations that only support SIP003. 3.2. ConfigurationShadowsocks implementation should add a new configuration key to enable SIP011. A recommended configuration key is {
"plugin": "PLUGIN program",
"plugin_opts": "PLUGIN options",
// plugin_mode can be:
// - "tcp_only" (default) - SIP003
// - "tcp_and_udp" - SIP011
// - "udp_only" - SIP011
"plugin_mode": "tcp_and_udp"
} 3.3. ImplementationPlugins should start a UDP listener
|
Unfortunately no. V2Ray itself doesn't support UoT as far as I know. |
@jan-bar hi, could I buy that plugin from you? Trying to setup UDP too. |
@jan-bar if you dont mind, please update your readme page with contact details, we have custom case, perhaps we could hire you for some consultation. :) |
last update was some time ago, may I ask what is the status of this proposal? I see the issue still open, but at the same time some references already to SIP003u in shadowsocks-rust Readme. so far my understanding is this feature is supported by following plugins appreciate if you could provide an update and confirm my understanding |
Just implement a sip003u plugin over websockets based on libevent. @zonyitoo It seems there is no way for the plugin to know the plugin mode. |
Why would the plugin need to know the plugin mode? It can always run in SIP003u even if the shadowsocks client only supports SIP003. |
@zonyitoo As sip003u is not implemented by all shadowsocks implementations, and it's not default even in shadowsocks-rust, if the plugin know it's not supported, then it can fast fail instead of the udp timeout. |
And, finally, there is a new plugin support sip003u: |
@zonyitoo Could you edit your comment, modify the sip003 url to https://shadowsocks.org/doc/sip003.html And, should this proposal add an implementation guide, like udp should always redirect the content of recvfrom / sendmsg and sendto / sendmsg in one udp packet? |
@jan-bar Coud you replace the image by link (and with a mention it's in chinese) or decrease the default size? |
@zonyitoo |
Don't show large chinese image in this issues. |
@janisblaus You can try the wss-proxy. |
I didn't check whatsapp call, however, I check the wechat video call, and it works well. |
As a new generation of proxy protocols emerges, good robust UDP support has become a holy grail when designing a new proxy protocol. XTLS/Xray-core makes aggressive architectural changes and adds patches over v2ray to make the proxy act like a full-cone NAT when handling UDP traffic. Qv2ray/gun is an experimental proxy implementation that utilizes gRPC to proxy TCP and UDP traffic.
However, the original proposal of SIP003 didn't include support for UDP. The lack of UDP support has significantly limited the possible use cases of SIP003.
I'm starting this discussion in the community to draft an UDP extension for SIP003 plugins. Feel free to post your ideas and suggestions down there.
TODO
Edit to add draft proposal details.
The text was updated successfully, but these errors were encountered: