Slashdot Mirror
Erlang and OpenFlow Together At Last
New submitter SIGSTOP writes "The LINC [OpenFlow 1.2 software-based] switch has now been released as commercial friendly open source through the FlowForwarding.org community website, encouraging users and vendors to use LINC and contribute to its development. The initial LINC implementation focuses on correctness and feature compliance. Through an abstraction layer, specialized network hardware drivers can be easily interfaced to LINC. It has been implemented in Erlang, the concurrent soft-real time programming language invented by Ericsson to develop their next generation networks."
what OpenFlow is, and the OpenFlow link goes to a non-existent page.
Link was missing a ":" - https://www.opennetworking.org/standards/intro-to-openflow
Here's wikipedia: http://en.wikipedia.org/wiki/OpenFlow
I used Erlang once before, in a previous job. What a fucking nightmare.
It's certainly different from your average OO language, but it's no more "a fucking nightmare" than other functional languages like haskell and ocaml.
I don't like either because I believe garbage collection is a bad idea - the programmer should have full control, and it's the job of the language to expose flaws, not hide them.
I know I'm in the minority here, but still I look back to the days of (pre-turbo) pascal and (pre-95) Ada with fondness.
But really, Erlang is one of the better functional languages, as they go. It may be tough to learn, but it has enough software written in it to prove its wirth.
It may be tough to learn, but it has enough software written in it to prove its wirth.
I'm not sure Wirth had much to do with Erlang.
Should be https://www.opennetworking.org/standards/intro-to-openflow
thegodmovie.com - watch it
Openflow is a protocol to let various routers communicate and coordinate how they route packets. That's my understanding of it. Google says they've gotten substantial efficiency improvements using it.
Erlang, of course, is a language designed to be as reliable and fault-tolerant as possible. I didn't know they used it in routers, but apparently some people want to.
"First they came for the slanderers and i said nothing."
I don't propse to start another to-GC-or-not-to-GC thread here. I'll just say my piece and that's it.
GC is sometimes a bad idea, and sometimes a good idea. It depends entirely on precisely what the programmer is doing.
Programs written in languages without some facility to enable automated or semi-automated memory management (be it full GC, reference-counted smart pointers or what have you) tend to be inherently non-modular. Somebody has to know when nobody else wants some object any more. There are essentially two solutions: either everyone is responsible for co-operative book-keeping (introducing boilerplate everywhere), or the program is structured around the lifetimes of data (potentially limiting what you can do algorithmically or making high-level reorganisation unnecessarily painful).
Sometimes none of that matters, or other concerns dominate. That's okay. If you spend all of your career working in niches where memory management must be manual or else, and you enjoy it, then I'm glad you've found your calling.
But for the majority of is, GC is another tool in our toolbox. It is part of my job to decide which tools are suitable for a given task and which ones are not. Hell, most of the time, semi-automated reference counting is more than enough. But sometimes, only GC will do the job.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
And you still hang out on slashdot, rather than reddit or Y combinator. Don't worry, you're probably not in a minority here.
xkcd is not in the sudoers file. This incident will be reported.
And just like manual memory management is a clamp on the foot for modularity in a single-threaded environment, manual locking and mutexes is an additional clamp on the foot for modularity in the multithreaded realm.
Erlang's actor model is an attempt to enable the production of modular concurrent communication software, just as Java's garbage collection model is an attempt to enable the production of modular business data software.
xkcd is not in the sudoers file. This incident will be reported.
Erlang Solutions will be providing the support structure for this, you can look at the packages offered here: http://www.erlang-solutions.com/section/84/support-plan-overview.
The Wknd Sessions - Malaysian and South East Asia independent music
Erlang's actor model is also just another tool in our toolbox.
Threads with shared memory, manual locking, mutexes, condition variables, restartable transactions and so on are hard to use. But that can also be okay. Sometimes the problem you're solving is so simple that it doesn't really matter, and sometimes it's so hard that there's no better way.
Having said that, of course, Erlang is closer to what Alan Kay meant when he coined the term "object oriented" than pretty much any other language has yet realised.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
You can for instance implement Layer 3 routing by dynamically changing the switch matrix on Layer 2. Essentially, IP adresses then become fancy MACs, and you know which IP adresses are reachable behind which port, allowing you to handle routing on Layer 2. Similarly you could implement higher level protocols to change your switch matrix, handle TCP errors already in the switch, saving hops and packets etc.pp.. In the end you get a box which seems to run each layer at wire speed.
In some way this runs contrary to the Layer model, because you use higher level layers to just remap the Layer 2, but if you implement it transparently (e.g. the box looks correctly at each layer), it is just very fast without disturbing the layering.
Erlang is closer to what Alan Kay meant when he coined the term "object oriented" than pretty much any other language has yet realised
I'm not sure it's still there, but there used to be a thing on the Erlang web page that said that Erlang was 'not an object oriented language like...' and then listed a number of other languages that were all less object oriented than Erlang.
I am TheRaven on Soylent News
In the end you get a box which seems to run each layer at wire speed.
That, if data in the traffic do not change much. From the ONF site, the router has to consult with the software what to do with the unrecognized packet. That cannot be fast. What's more, unless they change order of packets, the router would have to stall the traffic on the port. If change of order is deemed acceptable, they can go on routing other packets, but in the mean time other packets requiring software introspection might come and they would have to be buffered. Buffering on router is bad, because later comes the problem of how to insert the now-cleared-for-delivery packets in the stream.
All in all, I do not see how even theoretically it can be "at wire speed": either lots of out of order packets with selectively long latencies or long stalls. More flexible and complicated you want it to be, more exotic cases you want to catch - the more overhead that would introduce.
N.B. considering potential amount of traffic going through a 16-port gigabit ethernet router, the forwarding of some share of the traffic to the remote software for introspection (and receiving responses from it) would potentially require duh 16 gigabit ethernet ports.
I'll go read the white papers, but it all looks pretty funny to me.
In some way this runs contrary to the Layer model, because you use higher level layers to just remap the Layer 2, but if you implement it transparently (e.g. the box looks correctly at each layer), it is just very fast without disturbing the layering.
Man, real networks pretty much never followed Layer model. It makes sense only on the paper. The likes of ARP and ICMP and DHCP fit the layer model only in mind of the most delusional. Networks were always built around RFC 1925, (1). Layer model is more of RFC 1925, (6a).
All hope abandon ye who enter here.
Erlang is a functional language first , OO second. Smalltalk was designed to be OO from the ground up. In smalltalk even first class objects such as integers have methods and can be passed messages. Thats taking it too far IMO , but you can't get any more OO than that.
Or am I missing something profound?
Probably.
Functional programming leads to a completely different set of coding idioms. These can be very convenient in many applications. Since it is not the kind of programming that most people are used to, it can be awkward at first. There are a lot of things that are much more elegant and obvious when done this way, but you have to get over the barrier of thinking procedurally first. I would say that it isn't simply that hard core CS types like the aesthetics of functional programming. I think it's more that, being hard core CS types, they are exposed to functional programming and once the get immersed find it easier to express what they want to say.
Of course there is nothing really stopping you from writing functional code in any language. It's just that notationally, functional languages make it much easier. In the same way, you could write object oriented code in any language, but the verbosity would negate it's usefulness.
Personally, I don't think a programmer's education is complete without achieving some level of fluency in functional programming. Personally, I sadly lack any competence at all and I really should spend more time practicing.
By definition, functional languages require complex, structured return types. Typically implementations use nested lists (where items are referenced by position) or nested hashes (where items are referenced by name). It's not hard to implement these data structures in simple languages like C, but as you said, the verbosity would negate it's usefulness.
But anyway, the problems with functional ideoms only start at this point. To take a made-up example in Perl syntax:
sub foo($) {
return $_[0] == 1
? { key => +1, value => bar() }
: { key => -1, value => baz() };
}
What is the return type of foo? Without looking at the implementation of bar and baz you cannot tell. Functional languages make it very hard to separate interface and implementation. It takes a lot of support by the run-time systems and development tools to make up for it.
Post tenebras lux. Post fenestras tux.
...or want the language to be accessible to people who don't get their jollies golfing things into rpn notation and actually want to get some real work done.
Go forth and get some real work done then!