Closed sticnarf closed 7 years ago
Thank you for your PR.
I'm a bit devastated that such issues occur in the wild. TCP is stream-oriented and does not have packet boundaries, therefore shadowsocks is clearly broken? Is the project aware of this?
Could you please clarify if this is just a workaround or do I have a wrong understanding of TCP? I'll merge it then. Do you wish for a new Gem release?
BTW: I haven't actively written Ruby in many years. Would you take over maintainership?
I agree with you.
I do doubt whether the implementation of shadowsocks is valid. I will consult the maintainer of shadowsocks as to this issue.
It is a workaround in my opinion. I made a PR here because the solution is quite simple and does not make any change in nature (hence no worries about regression).
As a freshman at university, I do not have enough knowledge of network protocols. So, let me reject the maintainer work for lack of competence. :)
Now the issue is fixed in shadowsocks/shadowsocks-libev. The maintainer admits that all current shadowsocks implementations just assume there is no fragmentation on loopback in the handshake stage.
As to this PR... Merge or close, as you like...
Published as 1.7.1.
Thank you very much for taking care of this interop problem in both projects. I am happy to follow Postel's Law
As a freshman at university, I do not have enough knowledge of network protocols. So, let me reject the maintainer work for lack of competence. :)
Where else are you going to learn that if not with a tiny library like this one? :)
Some SOCKS servers, such as shadowsocks/shadowsocks, don't support to read the request details bit by bit.
And according to RFC 1928, it is implied that the request details need constructing before being sending to the server.
This pull request may also resolve #27 .