41–50 of 62 posts
Why not just? Linux: iptables -t nat -A PREROUTING -p tcp -s 192.168.20.200/0 -d 192.168.0.100/0 --dport 8080 -j REDIRECT --to-ports 20000 Windows: netsh interface portproxy add v4tov4 listenaddress=192.168.20.200 listenport=8080 connectaddress=192.168.0.100 connectport=20000 protocol=tcp
As someone who has also written a TCP proxy (along with many others...), after thoroughly reading the page I'm still unsure of how exactly this is "high performance". It is also curious that, despite the fact that it uses a separate library for networking, the source is already quite a bit longer than some other proxies which don't. I found the explanation overly complex. Around half the code in this implementation c…
> If A closes, close B. If B closes, close A. It's shutdown() writes on EOFs, not close, with refcounting to also do close() when EOFs were detected on both directions (I also have written a TCP proxy). But yeah, TCP proxies are trivial, would be more interesting to see something like a tunneling proxy that sends data over multiple connections to maximize performance.
Earlier quoted context omitted.
Netty is a more mature foundation for this sort of thing and likely much faster
Netty was first released in 2016? HAproxy was first released around 2001. Probably irrelevant to the question of speed, but there is a comment in another thread about hype driven development on HN first page right now where a commenter states they prefer Netty to the alternatives apparently because the alternatives are older or more cumbersome to use, although I may have misread. Edit: This was a hasty, dumb comment.…
Why not just? Linux: iptables -t nat -A PREROUTING -p tcp -s 192.168.20.200/0 -d 192.168.0.100/0 --dport 8080 -j REDIRECT --to-ports 20000 Windows: netsh interface portproxy add v4tov4 listenaddress=192.168.20.200 listenport=8080 connectaddress=192.168.0.100 connectport=20000 protocol=tcp
Earlier quoted context omitted.
> If A closes, close B. If B closes, close A. It's shutdown() writes on EOFs, not close, with refcounting to also do close() when EOFs were detected on both directions (I also have written a TCP proxy). But yeah, TCP proxies are trivial, would be more interesting to see something like a tunneling proxy that sends data over multiple connections to maximize performance.
Hey, I am looking for a way of packing multiple TCP streams over a single TCP connection to a backend server. I can unpack them in application logic if necessary. Do you know what that is called? Kinda like SCTP
Very nice, but this is more of a demo code for boost::asio than something that is production-worthy. For example, it doesn't relay FINs between connections, doesn't disable Nagle algorithm on the upstream socket, doesn't wait for pending writes to complete before tearing down the connection, doesn't handle congestion at all (potentially leading to unbound memory use), etc.
Earlier quoted context omitted.
It blows my mind that this is on the front page. It's not useful for anything, doesn't fully work, and can be replicated with a few lines on the console of BSD/Linux/windows.
Reminds of the time a friend wanted my opinion on a quote he received that it would take a week to open a socket in Unix using C code
Very nice, but this is more of a demo code for boost::asio than something that is production-worthy. For example, it doesn't relay FINs between connections, doesn't disable Nagle algorithm on the upstream socket, doesn't wait for pending writes to complete before tearing down the connection, doesn't handle congestion at all (potentially leading to unbound memory use), etc.
Could you point to an open source TCP proxy that you'd consider production worthy with an approachable code base?
Earlier quoted context omitted.
Could you point to an open source TCP proxy that you'd consider production worthy with an approachable code base?
http://nginx.org
Very nice, but this is more of a demo code for boost::asio than something that is production-worthy. For example, it doesn't relay FINs between connections, doesn't disable Nagle algorithm on the upstream socket, doesn't wait for pending writes to complete before tearing down the connection, doesn't handle congestion at all (potentially leading to unbound memory use), etc.
Could you point to an open source TCP proxy that you'd consider production worthy with an approachable code base?