是否可以将 socks5 servier/client, shadowsocks client/server 拆成 crate

[gfreezy]

我希望使用 socks5 client 和 shadowsocks client 的代码，但是目前没有拆分成 crate，没法依赖。

我现在的方法是拷贝 ss-rust 的代码到我自己的代码库里面，很难维护

[zonyitoo]

为什么没法依赖？shadowsocks本身是个lib?

[zonyitoo]

这样暴露出来是否可以

use shadowsocks::relay::tcprelay::client::ServerClient;

let stream = ServerClient::connect(context, &addr, &svr_cfg).await?;

[gfreezy]

不太希望把其他的代码也依赖进代码库。拆分成 crate 的可以实现只依赖 ss client，其他的 ss server ，socks5 server 等就不依赖了。

[zonyitoo]

那工作量不小，还得拆出来一个中间的proto库，加密协议、ACL等

[gfreezy]

如果可以接受拆分，我可以尝试着拆一些

[zonyitoo]

这样每个部分都要做成一个crate发布出去。现在tokio他们也不用分crate的方式发布了

[zonyitoo]

感觉可以加一些feature，可以控制各个part的编译

[gfreezy]

socks5 的逻辑还挺独立的，感觉独立出来也是有价值的。其他的感觉可以用 feature 控制

[raintean]

这样暴露出来是否可以

use shadowsocks::relay::tcprelay::client::ServerClient;

let stream = ServerClient::connect(context, &addr, &svr_cfg).await?;

看了现在master的ServerClient, 中间有涉及到Context, 是否可以把Context抽到更上一层, 把ServerClient做得更加纯粹一点, 尤其是Context还包含了对于Proxy和Direct的判断.
目前我正在实现一个类似于Surge的工具, 中间有用到ss的支持, 之前用golang实现的时候, go-shadowsocks对于纯粹的ss 加密stream实现比较干净, 所以new stream, 然后pipe就OK了. 但是shadowsocks-rust目前的这个实现有侵入性.

[gfreezy]

@raintean 我之前做了个一样的东西：https://github.com/gfreezy/seeker 。我是直接把 ss-rust 代码拷贝过去修改了

[raintean]

@raintean 我之前做了个一样的东西：https://github.com/gfreezy/seeker 。我是直接把 ss-rust 代码拷贝过去修改了

很棒啊, 我看你用的smoltcp做的netstack, 为什么没有选lwip?

[gfreezy]

@raintean 我之前做了个一样的东西：https://github.com/gfreezy/seeker 。我是直接把 ss-rust 代码拷贝过去修改了

很棒啊, 我看你用的smoltcp做的netstack, 为什么没有选lwip?

没听过 lwip。搜了下好像 lwip 是 C 写的，需要自己写 FFI ？

[raintean]

@gfreezy 是需要FFI的, 所以可能包含unsafe代码, 但是对于tcp/ip stack实现的完整性, 应该比smoltcp要好一些. 另外如果你这个seeker只是在非iOS平台上用, 我建议你使用nat模式, 直接使用系统的tcp/ip stack来做ip packet -> tcp connection的聚合, 性能和稳定上那肯定是最好的. 具体实现参见 kone 的实现.

[zonyitoo]

@raintean

Context里主要需要用的是DNS Resolver和检查重复IV，相当于是Server的全局状态。go版本它没有这些功能支持所以不需要这些状态储存。
我感觉这些功能还是挺重要的，建议保留。或者有什么改造建议？

可以实现成直接用tokio自带的DNS Resolver去连接Proxy目标，然后不检查重复IV即可

[raintean]

如果涉及到IV的重复检测(防止重放攻击), 确实需要一块共享的存储来存这些东西. 当然也只有在Server中是需要的. 目前我只是稍微捋了一下代码, 了解并不深入, 所以说一下我粗浅的看法:

1. 针对Client Lib, 能有独立的实现(不代表独立的crate). 类似 SSTcpStream::new(服务器地址, 加密方法, 密钥) -> Stream(AsyncRead/AsyncWrite以及block包装下的Read/Write).
2. 针对Client Bin, 可以包含更加丰富的特性, 比如基于Domain Rule, GEOIP Rule, 但是本质上还是使用的Client Lib. 所以Lib既可以给别人用, 也可以自己用.
3. Server的实现如上, IV相关我觉的可以保留, 相当于new方法中还需要加一个全局的Context了.
4. Runtime独立, Lib的实现过程中不包含对async_std/tokio的特定依赖, 返回值 使用标准future, AsyncRead/AsyncWrite实现futures中的. 针对task的spwan可以自己实现一个方法, 通过feature来控制使用tokio/async_std的. 异步的Mutex等,亦是如此.

以上...
作为一个lib被其他开发人员使用的话, 可以说得上是相当完美了.

[gfreezy]

@gfreezy 是需要FFI的, 所以可能包含unsafe代码, 但是对于tcp/ip stack实现的完整性, 应该比smoltcp要好一些. 另外如果你这个seeker只是在非iOS平台上用, 我建议你使用nat模式, 直接使用系统的tcp/ip stack来做ip packet -> tcp connection的聚合, 性能和稳定上那肯定是最好的. 具体实现参见 kone 的实现.

之前没想到这个方法。回头试一下，性能应该会提升不少。

[raintean]

@gfreezy 是需要FFI的, 所以可能包含unsafe代码, 但是对于tcp/ip stack实现的完整性, 应该比smoltcp要好一些. 另外如果你这个seeker只是在非iOS平台上用, 我建议你使用nat模式, 直接使用系统的tcp/ip stack来做ip packet -> tcp connection的聚合, 性能和稳定上那肯定是最好的. 具体实现参见 kone 的实现.

之前没想到这个方法。回头试一下，性能应该会提升不少。

不仅仅是性能, 稳定性肯定是最好的, 毕竟用的是系统的stack

[gfreezy]

@gfreezy 是需要FFI的, 所以可能包含unsafe代码, 但是对于tcp/ip stack实现的完整性, 应该比smoltcp要好一些. 另外如果你这个seeker只是在非iOS平台上用, 我建议你使用nat模式, 直接使用系统的tcp/ip stack来做ip packet -> tcp connection的聚合, 性能和稳定上那肯定是最好的. 具体实现参见 kone 的实现.

之前没想到这个方法。回头试一下，性能应该会提升不少。

不仅仅是性能, 稳定性肯定是最好的, 毕竟用的是系统的stack

重构了下代码，简单了不少

[raintean]

@gfreezy 我记得smoltcp是没有添加ip packet的支持的, 你对以太网包做了解包和封包吗？

[gfreezy]

@gfreezy 我记得smoltcp是没有添加ip packet的支持的, 你对以太网包做了解包和封包吗？

我自己封了一个 IP 层的 tun device，然后改了 smoltcp 暴露了一些方法出来。

https://github.com/gfreezy/seeker/tree/v0.1.2/tun/src/iface

smoltcp 默认是从物理层往上处理的。但是 mac 目前对 tap 没有什么好的支持🤷‍♂️。

[spacemeowx2]

点个赞, 我还有一个建议就是同时发布lib和bin版本到crates.io上. lib版本不带Cargo.lock, bin版本引用lib, 否则Cargo.lock会影响使用者的依赖.

[zonyitoo]

@gfreezy tun/tap 这一套，最近我也想基于 smoltcp 搞一下，基于这个 issue 相关的事情，可以考虑一起来加到 sslocal ？

[gfreezy]

@gfreezy tun/tap 这一套，最近我也想基于 smoltcp 搞一下，基于这个 issue 相关的事情，可以考虑一起来加到 sslocal ？

有什么计划吗？我可以一起来弄

[zonyitoo]

Check issue 326.

最近改完了tokio v0.3，准备升级到v1.9.0，可以把整体结构改造一下。具体的实现方案可以讨论。

[gfreezy]

Check issue 326.

最近改完了tokio v0.3，准备升级到v1.9.0，可以把整体结构改造一下。具体的实现方案可以讨论。

最好不要绑定 tokio，现在 async-std 的使用也挺广的。讨论是直接在 issue 里面吗？

[zonyitoo]

Of course, you can.

[raintean]

@gfreezy tun/tap 这一套，最近我也想基于 smoltcp 搞一下，基于这个 issue 相关的事情，可以考虑一起来加到 sslocal ？

有什么计划吗？我可以一起来弄

@zonyitoo 请带上我, 我写过lwIP包装的

[zonyitoo]

看issue吧，我考虑是拆成local和server，基础的实现放在core里面。基于tun/tap这套可以通过扩展local来做，或者直接调用core的函数来实现