Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serve2d – A protocol detecting server

github.com

Post reply on HN
Print view View original

11–20 of 77 posts

Re: Serve2d – A protocol detecting server

#11

Post by boomzilla »

rogerbinns wrote: post #8
IgorPartola wrote: post #4

Earlier quoted context omitted.

So here's what hopefully won't be considered a trolling question: I have seen a lot of "100% Go" projects over the past several years and that's usually presented as a big feature. Some pretty trivial things have been redone as brand new in Go, and then suddenly gain lots of attention. What is so magical about a project written in Go vs C, Python, Ruby, Rust, JS, etc.? As a user of the software I won't care what it's…

Go produces a single static binary. Consequently deploying go apps is as simple as copying a single file around, that just works.

Believe it or not, you can freeze binaries for python apps too, if you like: https://wiki.python.org/moin/Freeze

Re: Serve2d – A protocol detecting server

#13

Post by wakaflockafliz »

rogerbinns wrote: post #8
IgorPartola wrote: post #4

Earlier quoted context omitted.

So here's what hopefully won't be considered a trolling question: I have seen a lot of "100% Go" projects over the past several years and that's usually presented as a big feature. Some pretty trivial things have been redone as brand new in Go, and then suddenly gain lots of attention. What is so magical about a project written in Go vs C, Python, Ruby, Rust, JS, etc.? As a user of the software I won't care what it's…

Go produces a single static binary. Consequently deploying go apps is as simple as copying a single file around, that just works.

@boomzilla: Go head and try it IRL. It's a huge PITA and there are plenty of gotchas.

Re: Serve2d – A protocol detecting server

#14

Post by falcolas »

BillinghamJ wrote: post #12

Why? The entire point of ports is so you don't have to do this. Don't get me wrong, it's kinda cool, but it seems like a really bad idea to actually do it.

There are a number of work and wifi proxies which won't allow out a lot of traffic, based on port. A multiplexer like this can work around such (assumed) well-intentioned but poorly implemented protections.

Re: Serve2d – A protocol detecting server

#15

Post by BillinghamJ »

falcolas wrote: post #14
BillinghamJ wrote: post #12

Why? The entire point of ports is so you don't have to do this. Don't get me wrong, it's kinda cool, but it seems like a really bad idea to actually do it.

There are a number of work and wifi proxies which won't allow out a lot of traffic, based on port. A multiplexer like this can work around such (assumed) well-intentioned but poorly implemented protections.

Wouldn't a VPN or tunnelling solution be better? You pass all your traffic through a fixed port on one host, then unwrap it and use the web as though the restriction wasn't there.

Re: Serve2d – A protocol detecting server

#16

Post by veeti »

rakoo wrote: post #10
IgorPartola wrote: post #4

Earlier quoted context omitted.

So here's what hopefully won't be considered a trolling question: I have seen a lot of "100% Go" projects over the past several years and that's usually presented as a big feature. Some pretty trivial things have been redone as brand new in Go, and then suddenly gain lots of attention. What is so magical about a project written in Go vs C, Python, Ruby, Rust, JS, etc.? As a user of the software I won't care what it's…

The number 1 selling point of something written in Go is that it's much easier to package. The result of a compilation is a standalone binary that can be copy-pasted everywhere, as long as the architecture matches what was input at compilation time. This means: - no more having to deal with dependencies at packaging time, which makes packagers' job simpler because all they have to care is the one and only standard wa…

> This also means that there's a higher chance that the software will be packaged in the distribution of your choice, because the bar is lower

Static linking and bundling of dependencies is a no-no in most distributions. If anything, the Go model is a headache for package maintainers to deal with.

Re: Serve2d – A protocol detecting server

#17

Post by ZenoArrow »

serve2d looks promising, can see some good uses for it.

If anyone's interested, Corkscrew is an alternative solution, allows you to disguise SSH as HTTP/HTTPS traffic, useful for getting through restrictive firewalls to administer remote machines:

https://github.com/elia/corkscrew

Re: Serve2d – A protocol detecting server

#18

Post by pmelendez »

rakoo wrote: post #10
IgorPartola wrote: post #4

Earlier quoted context omitted.

So here's what hopefully won't be considered a trolling question: I have seen a lot of "100% Go" projects over the past several years and that's usually presented as a big feature. Some pretty trivial things have been redone as brand new in Go, and then suddenly gain lots of attention. What is so magical about a project written in Go vs C, Python, Ruby, Rust, JS, etc.? As a user of the software I won't care what it's…

The number 1 selling point of something written in Go is that it's much easier to package. The result of a compilation is a standalone binary that can be copy-pasted everywhere, as long as the architecture matches what was input at compilation time. This means: - no more having to deal with dependencies at packaging time, which makes packagers' job simpler because all they have to care is the one and only standard wa…

> no more having to deal with dependencies at runtime

So, it is the same that linking the libraries statically? C and C++ has done that like since forever.

Re: Serve2d – A protocol detecting server

#19

Post by oasisbob »

BillinghamJ wrote: post #12

Why? The entire point of ports is so you don't have to do this. Don't get me wrong, it's kinda cool, but it seems like a really bad idea to actually do it.

It's not a bad idea, though I'm not sure why someone would want to do this on their own in a bolt-on manner. For an example of a place where demux is encouraged, see RFC 6335:

Conservation of the port number space is required because this space is a limited resource, so applications are expected to participate in the traffic demultiplexing process where feasible. The port numbers are expected to encode as little information as possible that will still enable an application to perform further demultiplexing by itself. [...] IANA strives to assign only one assigned port number per service or application.

Why do I know this? Consul by default uses 5-6 ports, and one of them conflicts with an IETF registered port in-use by our data center provider. Was hoping that the RFCs gave some ammo for a resolution in my favor, came out more humble and wondering if Consul really needed that many ports.

Re: Serve2d – A protocol detecting server

#20

Post by sigjuice »

BillinghamJ wrote: post #15
falcolas wrote: post #14

Earlier quoted context omitted.

There are a number of work and wifi proxies which won't allow out a lot of traffic, based on port. A multiplexer like this can work around such (assumed) well-intentioned but poorly implemented protections.

Wouldn't a VPN or tunnelling solution be better? You pass all your traffic through a fixed port on one host, then unwrap it and use the web as though the restriction wasn't there.

VPN or tunneling solutions are unlikely to work if severe network restrictions are in place. e.g. firewalls that only allow TCP ports 80 and 443.
Post reply on HN