Study sources

[EbrahimTahernejad]

Hey!

Thank you for the hard work you've done. You've been a big help to the community, especially those of us who are struggling to keep a 50MB limit 😄.

I wanted to learn more about this project and contribute (plus I have some ideas in mind). So I decided to study more.

If you would be so kind to share any sources that comes to mind, I would appreciate it, especially on the tun2socks part (sessions, managing packet headers, etc.).

Thank you

[itsDantes]

@EbrahimTahernejad what you mean about 50MB limit

[EbrahimTahernejad]

In iOS, there is a thing called NetworkExtension, which is basically a process that creates a network interface. You can read/write packets from/to it using a user-level API or a file descriptor.

That process has a 50MB memory limit (Before iOS 15 it was 15MB).

So, if you are using Xray + Tun2Socks, the memory usage of these two together should not exceed 50MB.

[heiher]

@EbrahimTahernejad If you have specific thoughts or questions, we can discuss that.

[heiher]

In iOS, there is a thing called NetworkExtension, which is basically a process that creates a network interface. You can read/write packets from/to it using a user-level API or a file descriptor.

That process has a 50MB memory limit (Before iOS 15 it was 15MB).

So, if you are using Xray + Tun2Socks, the memory usage of these two together should not exceed 50MB.

Thanks. Is it possible to just run tun2socks in this process and xray in another? tun2socks and xray communicate through socket. :smiley:

[EbrahimTahernejad]

Thanks. Is it possible to just run tun2socks in this process and xray in another? tun2socks and xray communicate through socket. 😃

No, sadly you can't spawn a process easily, we mostly use extensions to achieve that, but even in extensions, only NetworkExtension is able to run in background constantly. Plus, only one NetworkExtension can run at the same time on the whole OS, meaning we have to fit Tun2Socks + Xray in one process with a 50MB ram limit.

[itsDantes]

@EbrahimTahernejad is there any limitation in android like what you said?

[itsDantes]

@heiher thanks for your work. i use it in my projects. your lib give me more stable ping. if there is anything else that can improve my tunnel ping please tell me.

[heiher]

@heiher thanks for your work. i use it in my projects. your lib give me more stable ping. if there is anything else that can improve my tunnel ping please tell me.

icmp?

[EbrahimTahernejad]

@EbrahimTahernejad If you have specific thoughts or questions, we can discuss that.

Well, as you might know, we can use swift with c/cpp. I want to create tun2X where X stands for proxy protocols like vmess, vless, ss, etc. So my goal is to use your code base as a packet -> socket manager with custom handshake process, encoding, etc., and later write a tun2X purely in Swift.

[heiher]

@EbrahimTahernejad If you have specific thoughts or questions, we can discuss that.

Well, as you might know, we can use swift with c/cpp. I want to create tun2X where X stands for proxy protocols like vmess, vless, ss, etc. So my goal is to use your code base as a packet -> socket manager with custom handshake process, encoding, etc., and later write a tun2X purely in Swift.

I believe SOCKS5 serves as a superior glue layer, supporting both TCP and UDP with lightweight and minimal overhead. Utilizing SOCKS5 between tun2socks and other protocols is a wise choice, given its compatibility, and many protocol implementations offer SOCKS5 server support.

[EbrahimTahernejad]

I believe SOCKS5 serves as a superior glue layer, supporting both TCP and UDP with lightweight and minimal overhead. Utilizing SOCKS5 between tun2socks and other protocols is a wise choice, given its compatibility, and many protocol implementations offer SOCKS5 server support.

The thing is, the current Xray/Sing-box cores are efficient, but they can be implemented in a more memory-efficient manner, what I'm trying to do is to connect your code, to my own implementation of these protocols.

[heiher]

I believe SOCKS5 serves as a superior glue layer, supporting both TCP and UDP with lightweight and minimal overhead. Utilizing SOCKS5 between tun2socks and other protocols is a wise choice, given its compatibility, and many protocol implementations offer SOCKS5 server support.

The thing is, the current Xray/Sing-box cores are efficient, but they can be implemented in a more memory-efficient manner, what I'm trying to do is to connect your code, to my own implementation of these protocols.

Write a simple socks5 server for it. 😆

[Ali-Khazaee]

I am using hev-socks5-tunnel too, It's fine already. I think it will be more efficient if we remove our limits ( only SOCKS ) and provide an interface to implement custom protocols and use SOCKS as default.

I think using SOCKS as glue layer will divide the performance by 2.

because Tun2Socks create client connection to a local Socks5 server, so the READ/WRITE will be called twice, once for local, and once for remote connection ( double read/write system call, double file descriptor per connection, double buffer for each connection)

[heiher]

I am using hev-socks5-tunnel too, It's fine already. I think it will be more efficient if we remove our limits ( only SOCKS ) and provide an interface to implement custom protocols and use SOCKS as default.

I think using SOCKS as glue layer will divide the performance by 2.

because Tun2Socks create client connection to a local Socks5 server, so the READ/WRITE will be called twice, once for local, and once for remote connection ( double read/write system call, double file descriptor per connection, double buffer for each connection)

Yes. This is indeed the case with the current I/O model. I'm writing new I/O APIs to support chained calls. This will help eliminate the additional overhead here.