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

21–30 of 77 posts

Re: Serve2d – A protocol detecting server

#21

Post by debaserab2 »

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.

Different, but not better depending on your requirements. Tunneling over a VPN can be pretty slow.

Re: Serve2d – A protocol detecting server

#22

Post by rektide »

IgorPartola wrote: post #4
wakaflockafliz wrote: post #3

Earlier quoted context omitted.

That is certainly part of the inspiration and legacy behind serve2d. This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)

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…

A staid, solid, conservative outlook, a good perspective for others to realize is out there. I would say that concerns like daemon mode and logging are a lot less in vogue these days- a program ought concern itself with running, and outputting to stdout, and if you have needs past these it's expected you have tooling you can deploy that makes that happen.

Daemonization is at least a fairly standard feature, but with logging there's so many people with such varied concerns that getting fancy, trying to meet people's many needs, can lead to a lot of program bloat very quickly. Instead of going at these on a case-by-case basis, and now that we are more container-centric, it makes sense to run in the foreground and put your output on stdout, let the rest of the system support that utterly uncomplex pattern.

Re: Serve2d – A protocol detecting server

#23

Post by cbhl »

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.

Generally these well-intentioned networks block the usual VPN and tunneling solutions (think kid and a school network with a firewall that only allows FTP, HTTP, and HTTPS).

Re: Serve2d – A protocol detecting server

#24

Post by poizan42 »

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.

That's a very weird way to look at it. Static linking was there before everything else. gcc/ld and, well, any other C/C++ toolchain can do that as well. There is a reason this isn't usually done. It's like you are trying to spin a bad thing into something good.

Re: Serve2d – A protocol detecting server

#25

Post by poizan42 »

ZenoArrow wrote: post #17

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

It doesn't disguise it does it? I think it just uses the CONNECT support in proxies. You need something like httptunnel to disguise the traffic.

Re: Serve2d – A protocol detecting server

#26

Post by Hello71 »

wakaflockafliz wrote: post #3
sschueller wrote: post #2

Or use the good old sslh: http://www.rutschle.net/tech/sslh.shtml

That is certainly part of the inspiration and legacy behind serve2d. This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)

previously: https://github.com/JamesDunne/sslmux

Re: Serve2d – A protocol detecting server

#27

Post by falcolas »

cbhl wrote: post #23
BillinghamJ wrote: post #15

Earlier quoted context omitted.

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.

Generally these well-intentioned networks block the usual VPN and tunneling solutions (think kid and a school network with a firewall that only allows FTP, HTTP, and HTTPS).

Doesn't even have to be that nefarious - I am blocked from using my OpenVPN tunnel (UDP and TCP) from at least two restaurants that I'm aware of.

Re: Serve2d – A protocol detecting server

#28

Post by wakaflockafliz »

Hello71 wrote: post #26
wakaflockafliz wrote: post #3

Earlier quoted context omitted.

That is certainly part of the inspiration and legacy behind serve2d. This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)

previously: https://github.com/JamesDunne/sslmux

That looks like a start but implements only a fraction of the usefulness.

Re: Serve2d – A protocol detecting server

#29

Post by superuser2 »

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.

Blocking all ports but 80 and 443 is "the firewall" and therefore a very large component of any enterprise security policy.

Re: Serve2d – A protocol detecting server

#30

Post by wpietri »

IgorPartola wrote: post #4
wakaflockafliz wrote: post #3

Earlier quoted context omitted.

That is certainly part of the inspiration and legacy behind serve2d. This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)

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…

I think the the "100% Go" stuff is appealing in that you just have one file that works across OSes, with minimal screwing around.

For things that become part of the OS, yes, I'd rather they come via some install approach that includes the necessary integration. But for anything else, I think a lot of our packaging approaches are dedicated to saving disk space and RAM, which is something that matters way less to me now than it did 15-20 years ago when CPAN and APT were designed. In 2000, disk prices were circa $10/GB [1]; now we're looking at $0.50/GB of zippy SSD [2] or $0.03/GB of spinning rust [3]. RAM is similarly about 2 orders of magnitude cheaper. [4] Given that, it makes a lot more sense to burn space to minimize the chance of a library version conflict or other packaging issue.

Another thing that has changed greatly is the pace of updates. 15-20 years ago, weekly releases sounded impossible to most. Now it's common, and some places are releasing hourly or faster. [5] Thanks to things like GitHub, the whole notion of a release is getting hazy: I see plenty of things where you just install from the latest; every merge to master is in effect a new release.

Given that, I think both Go and Docker are pioneering approaches that are much more in sync with the current computing environment. I'm excited to see where they get to.

[1] http://www.mkomo.com/cost-per-gigabyte-update

[2] http://techreport.com/review/27824/crucial-bx100-and-mx200-s...

[3]http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&Is...

[4] http://www.jcmit.com/mem2015.htm

[5] www.slideshare.net/InfoQ/managing-experimentation-in-a-continuously-deployed-environment slide 27

Post reply on HN