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

101–110 of 130 posts

Re: GoBGP: BGP Implemented in Go

#101

Post by coalescence »

tptacek wrote: post #98
_wmd wrote: post #93

Earlier quoted context omitted.

You bundle or create it yourself.. $ apt-get source bash $ cd bash*/ $ quilt new my_urgent_patch $ patch -p1

That's fine. I don't care what you do with your self-built binaries once you manage to build them yourself. But too many firms have no infrastructure in place to do that. They wait for upstreams to synchronize to fix security flaws that they could fix directly.

scp and "dpkg -i" are readily available, but it's really not that much work to setup a repository (aptly, reprepro, apt-ftparchive etc.)

I know I'd personally chose maintaining the system packages and where possible put extraneous language dependencies in packages too (fpm comes in handy as it can deal with a variety of packages, gem, npm etc). It makes life a lot simpler when it comes to administering a bunch of systems and trying to keep things consistent.

Re: GoBGP: BGP Implemented in Go

#102

Post by jacobparker »

pcwalton wrote: post #94
wolf550e wrote: post #64

Earlier quoted context omitted.

That's excellent and must be this way to allow programming microcontrollers or linux kernel modules in Rust, but you guys also need a blessed cross platform N:M threading async I/O sockets and files library, so people can write snmp/mail/web/etc servers/proxies/etc in Rust.

Few C implementations of these applications use M:N threading. M:N threading was tried early on in Linux's history and was abandoned for a reason. It is not a requirement for implementing those applications; in fact, it'll always be suboptimal from a performance point of view, especially in low-level languages like Rust. (Note that I'm not saying it's not fast enough for most applications, or that it was the wrong ch…

(Off-topic) what do you think about marshalling for continuations from await? So the issue where on one hand it's confusing/surprising if you don't default to marshalling the continuation back to the thread (etc.) that created the continuation (e.g. the UI thread) but if you do then mixed blocking and async this can result in deadlocks (contention on the thread/etc.)

.NET defaults to this, you can opt out (which you usually want to do, at least for correctness) by doing await Foo().ConfigureAwait( continueOnCapturedContext: false )

EDIT: my etc.'s are weaseling around the word thread... more details about .NET here: http://blogs.msdn.com/b/pfxteam/archive/2012/04/12/async-awa...

Re: GoBGP: BGP Implemented in Go

#103

Post by cyphar »

alanctgardner3 wrote: post #51
noja wrote: post #31

Earlier quoted context omitted.

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.

If you have an automated build system (like OBS -- the Open Build System used by openSUSE) where dependencies are rebuilt automatically and security fixes can be pushed to maintainence automatically.

Re: GoBGP: BGP Implemented in Go

#104

Post by 15155 »

steveklabnik wrote: post #72
wolf550e wrote: post #64

Earlier quoted context omitted.

That's excellent and must be this way to allow programming microcontrollers or linux kernel modules in Rust, but you guys also need a blessed cross platform N:M threading async I/O sockets and files library, so people can write snmp/mail/web/etc servers/proxies/etc in Rust.

So, mio is certainly becoming the core library everyone uses for async I/O, but N:M threading is more complex, and doesn't have any libraries that are mature enough yet to start consolidating. I think AIO is more important than the threading model for this kind of thing, personally, but it's also not exactly my area of expertise.

Can mio be pulled into the stdlib, then?

I fear a world of gevent/Twisted, EventMachine/Celluloid/base Ruby, Boost/a litany of other options.

Re: GoBGP: BGP Implemented in Go

#105

Post by tptacek »

pests wrote: post #82
tptacek wrote: post #78

Earlier quoted context omitted.

If the Debian people don't want to include Go for some logistical or religious or religiously logistical reason, that's fine with me. I don't think people should run critical infrastructure from Debian releases --- when things go wrong, you want to be prepared to patch source on a moment's notice, rather than waiting for the upstream synchronization dance --- but hardly anyone seems to agree with me on that, either.…

What is the cool trick to implementing BER?

you encode it back-to-front

i don't even

care

anymore.

Re: GoBGP: BGP Implemented in Go

#106

Post by pcwalton »

15155 wrote: post #104
steveklabnik wrote: post #72

Earlier quoted context omitted.

So, mio is certainly becoming the core library everyone uses for async I/O, but N:M threading is more complex, and doesn't have any libraries that are mature enough yet to start consolidating. I think AIO is more important than the threading model for this kind of thing, personally, but it's also not exactly my area of expertise.

Can mio be pulled into the stdlib, then? I fear a world of gevent/Twisted, EventMachine/Celluloid/base Ruby, Boost/a litany of other options.

I wouldn't mind pulling it into the standard library if we're sure it's mature enough to be ready. In the meantime, though, it's the de facto standard async I/O framework, and I don't see that changing anytime soon.

Re: GoBGP: BGP Implemented in Go

#107

Post by tptacek »

pcwalton wrote: post #92
15155 wrote: post #34

Earlier quoted context omitted.

RE: the (or Rust) comment- All of these services would be better suited for a language which has blessed async IO, concurrency, parallelism primitives. Go has these, Rust does not. pthreads are not the answer. I much prefer Rust, but Go's stdlib and concurrency features far exceed that of Rust at the moment.

> All of these services would be better suited for a language which has blessed async IO, concurrency, parallelism primitives. Go has these, Rust does not. pthreads are not the answer. Go does not have truly async I/O. It has a userspace (M:N) implementation of threaded, synchronous I/O. There is a distinction, and it's not an academic one. Rust uses the kernel-level (1:1) implementation of threaded, synchronous I/O,…

Can you be a bit clearer on the distinction here? It's "synchronous" in the sense that the code is straight-line synchronous, but threads are scheduled in part based on I/O events (IIRC, this used to be the primary way threads were scheduled).

Yes, every connection has a (small) thread stack associated with it. But in a "truly asynchronous" network program, every connection still has memory associated with it; it's just that the memory doesn't take the form of a procedure stack.

Re: GoBGP: BGP Implemented in Go

#108

Post by tptacek »

zzzcpan wrote: post #84
tptacek wrote: post #74

Earlier quoted context omitted.

There's no good predictable event-driven polling library for networking because the whole runtime is a good predictable event-driven polling library for networking. You're not supposed to "event" Go I/O. Virtually every Go program that anyone has deployed at scale has scaled I/O with goroutines (though not necessarily with "concurrent memory access"). With the exception of NTP, I can't see a single example of a servi…

You are not doing event-driven programming just to scale I/O, you are doing it to avoid mutexes and concurrent memory access, to have easy cancellation, easy management of connections and other resources, etc.

Idiomatic Go code also doesn't use mutexes and concurrent memory access, unless you're trying to argue that channels are implicitly mutexes. Also: you now seem to be subtly backing off your original point. Can we stipulate that the performance of most network programs would not be meaningfully improved by switching from M:N I/O scheduled threads to async I/O?

Re: GoBGP: BGP Implemented in Go

#109

Post by tptacek »

sre_ops wrote: post #57
tptacek wrote: post #30

Earlier quoted context omitted.

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.

Sendmail used to run on something like 90% of the global Internet. And mail in the 1990s pretty much did work, pretty reliably. Would you have banked your site's security on the quality of Sendmail 8.6.12's code?

Re: GoBGP: BGP Implemented in Go

#110

Post by nickpsecurity »

zzzcpan wrote: post #66
steveklabnik wrote: post #61

Earlier quoted context omitted.

Not anymore; it's in Go these days.

Translated to Go from C, to be precise, not completely reimplemented.

Precise in terms of what? I have no idea why parent brought up implemented in C. It usually is a person who thinks only C is low-level, fast, portable, or whatever enough to handle the task at hand due to shortcoming in other language being discussed. Compiler done in C implies Go wasn't good enough.

Compiler entirely in Go and very fast cancels that whole line of thinking. Far as precision, the original source could've been ported from COBOL and that wouldn't matter. The point would remain it's now in Go and gets the job done.

Post reply on HN