I have been following this project for a long time and I think the technology is very good. But today I suddenly thought of a very important question.

[sgf]

This project is a two-end TCP channel. This means that the TCP protocol on both sides needs to be taken over, and then the UDP protocol packets are transmitted as payload.
But I suddenly wondered what the point of doing this is?
If I can take over the basic logic of sending and receiving packets such as the sending and receiving flow control of the two-end TCP, then why should I send UDP protocol packets on this basis?
Because I can completely improve or rewrite the packet control of the TCP protocol, thereby controlling the flow, reducing latency, etc.
So if you think about it this way, Udp2Raw seems to be meaningless to a large extent.

[wangyu-]

Because I can completely improve or rewrite the packet control of the TCP protocol, thereby controlling the flow, reducing latency, etc.
So if you think about it this way, Udp2Raw seems to be meaningless to a large extent.

I don't get the logic of "If A is working, then B is useless". For the same problem, there are always alternative solutions.

Well your method works. Your method involves hacking tcp stacks for Linux,BSD, Windows. It will have a higher maintenance burden than udp2raw's method. Your method is more easily to be broken as OS' new versions are releasing.

If you kindly implemented your method 7 years ago, then I should have used your project and udp2raw might not exist at all. But sadly your implementation doesn't exist, I had to do this on my own.

Please kindly start you project now and make it stable on all the OSes. Then I will be very happy to use your project.

[sgf]

Your method involves hacking tcp stacks for Linux,BSD, Windows.

Not involved.

Just an idea, and after thinking it out, I found that it is essentially the same as Udp2Raw.It just comes without UDP.

So I realized that maybe this idea didn't make a lot of sense.So I closed it.

I am not good at network programming.