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

GoBGP: BGP Implemented in Go

github.com

Post reply on HN
Print view View original

51–60 of 130 posts

Re: GoBGP: BGP Implemented in Go

#51

Post by alanctgardner3 »

noja wrote: post #31
dsr_ wrote: post #23

Earlier quoted context omitted.

...well, because of the primary shortcoming of the Go system: lack of standard infrastructure to manage the inevitable updates. Let's say I have replaced bind, unbound, ntpd, postfix, openssh, dovecot, snmpd and asterisk with Go-written equivalents. Three weeks later, there is a bug found in the standard Go TLS library. My distro ships all the packages noted above, but not their Go-equivalents, so my work load now in…

So you install the go equivalents from your distro. If your distro doesn't have them, you vote for them to add them (or go through whatever process your distro has).

The repo maintainers are going to be on the hook to rebuild every dependency every time any package in the dependency chain changes. That sounds like a nightmare versus the current scenario where only one package gets revved when a library has a bug.

Re: GoBGP: BGP Implemented in Go

#52

Post by pjmlp »

dsr_ wrote: post #40
tptacek wrote: post #29

Earlier quoted context omitted.

No. I've written SNMP from scratch in Ruby, Python, and C++. DER ASN.1 for X.509 might be treacherous (simply in the sense that any mistake you make at all will be ruinous), but that's just not the case for SNMP's BER. The whole point of using Rust or Go instead of C is that the "peril" of implementing things like ASN.1/BER is pretty much eliminated. As for your former point: I don't follow. Go's deployment infrastru…

The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go/Rust equivalents, unless they handle packets directly. My objection is that you are advocating this in the same narrow-focused way that people advocate node with npm, python with pip, ruby with gem: little or no cooperation with the whole system is available yet. This is perfectly fine from the point of…

Static linking is also a thing in C.

Apparently gcc seems to be the only C compiler lacking this capability, thanks to glibc.

Also, you can use dynamic linking in Go since version 1.5.

Re: GoBGP: BGP Implemented in Go

#53

Post by hartator »

tptacek wrote: post #11

This is the sort of thing Go really shines on: network and infrastructure services that would ordinarily be provided by big ugly C programs, where the latency requirements are significant but not as bad as raw packet forwarding. If your current best alternative is a C program, I'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

I was thinking Go is implemented in C?

Re: GoBGP: BGP Implemented in Go

#54

Post by nickpsecurity »

JoachimSchipper wrote: post #25
tptacek wrote: post #11

This is the sort of thing Go really shines on: network and infrastructure services that would ordinarily be provided by big ugly C programs, where the latency requirements are significant but not as bad as raw packet forwarding. If your current best alternative is a C program, I'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

Because some C programs are pretty excellent, and rewrites cause bugs? E.g. replacing OpenNTPd, Postfix, OpenSSH - or djbdns or qmail - by a rewrite probably doesn't reduce the number of problems. (In particular, note that SSH daemons can fail in many ways other than by remote code execution.) In the long run, C's role is indeed shrinking - but let's not be too hasty.

You can always do it close to original implementation. A straight-up clone. Should preserve at least most of the logical-level countermeasures.

Re: GoBGP: BGP Implemented in Go

#55

Post by steveklabnik »

15155 wrote: post #49
steveklabnik wrote: post #43

Earlier quoted context omitted.

In general, almost every stdlib will be "better" than Rust's, as we're taking an "anti-batteries included" approach. And while Go does have great built-in stuff for a certain kind of concurrency, Rust's approach is more flexible and safer. It's a tradeoff, not a "far exceed" in my mind.

Isn't the Rust approach the Ruby, Python, or C++ approach?: give pthreads, rely on the community to produce a fragmented, incompatible ecosystem.

The Rust approach is, Rust's safety guarantees work for concurrency, but the details of that concurrency are left up to libraries, not the language. Since the safety is in the language, things are always safe, but you get the flexibility to do what you need.

You have to remember, Rust is a systems language. Which means that you need access to what the system gives you, and that means at least OS threads and both synchronous and asynchronous IO. We can't just decree "the world must use only aio and green threads", or we would be compromising Rust's fundamental design goals.

Re: GoBGP: BGP Implemented in Go

#56

Post by nickpsecurity »

npizzolato wrote: post #42
harshreality wrote: post #21

Earlier quoted context omitted.

bgp A project page for a $language implementation of $protocol shouldn't be expected to give a basic description of $protocol. If you care about a new implementation, you already know what the protocol does, at least generally. If you're lucky, the project page links to a protocol description (possibly at wikipedia), or, as above, you can simply google it yourself and then decide whether a $language implementation of…

I don't think it's a lot to ask for a readme to contain the full name of the acronym it's implementing and maybe a link to a wikipedia page. I mean, it already has a link to the golang website, but no mention of what BGP actually is.

A quick Google solves that problem. Anyone that wouldn't do that much is unlikely to be valuable to the project. It's a nice filter at the least.

Re: GoBGP: BGP Implemented in Go

#57

Post by sre_ops »

tptacek wrote: post #30
xorcist wrote: post #28

Earlier quoted context omitted.

Not really. Neither the BGP layer nor the packet forwarding layer in that big Cisco box of yours is moving away from C code. Standard network software such as Postfix and OpenSSH took ten years to replace their predecessors, and their eventual replacement will be just as gradual. It's not happening right now, so I think it's a bit of a stretch to call it a trend.

I didn't say it was. But then: I don't trust that Cisco C code at all . Do you?

Yes. It currently runs over 70% of global internet and considering all kinds of error conditions that show up on the global internet the code is extremely stable.

Re: GoBGP: BGP Implemented in Go

#58

Post by baq »

pjmlp wrote: post #52
dsr_ wrote: post #40

Earlier quoted context omitted.

The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go/Rust equivalents, unless they handle packets directly. My objection is that you are advocating this in the same narrow-focused way that people advocate node with npm, python with pip, ruby with gem: little or no cooperation with the whole system is available yet. This is perfectly fine from the point of…

Static linking is also a thing in C. Apparently gcc seems to be the only C compiler lacking this capability, thanks to glibc. Also, you can use dynamic linking in Go since version 1.5.

i don't know if it counts, but there's musl-gcc, right?

Re: GoBGP: BGP Implemented in Go

#60

Post by poooogles »

xorcist wrote: post #28
tptacek wrote: post #14

Earlier quoted context omitted.

"As much as it can". nftables and openvwitch both forward packets, and thus need to be written in C (or, perhaps, in the long term, Rust). Really, you're playing on a semantic ambiguity in the word "router". A BGP implementation doesn't forward packets; it maintains a database of forwarding paths that the packet forwarding layer consults. In a large Cisco router, the SOC that runs BGP and maintains the RIB isn't the…

Not really. Neither the BGP layer nor the packet forwarding layer in that big Cisco box of yours is moving away from C code. Standard network software such as Postfix and OpenSSH took ten years to replace their predecessors, and their eventual replacement will be just as gradual. It's not happening right now, so I think it's a bit of a stretch to call it a trend.

I thought the replacement of Telnet with OpenSSH was fairly fast? Few years at most, it seemed to almost happen over night compared to the move from SSL to TLS for example.
Post reply on HN