3 ms·

Yup. I'm sure every network programmer who's worth his salt has a version of stackable abstraction layers library that runs of epoll or a variation thereof, and

by eps 16y ago

Yup. I'm sure every network programmer who's worth his salt has a version of stackable abstraction layers library that runs of epoll or a variation thereof, and supports various transports from plain IP through domain sockets and to exotics like TLS over ICMP. It's like a rite of passage into the circle of network programming enlightenment :)

stcredzero 16y ago
I don't understand why HLL don't have some sort of standard abstraction on top of sockets. Is it because it's a fundamentally "leaky abstraction" or should it be done? Seems to me that most HLL attempts to abstract networking try to be too high level.
- mhd 16y ago
  Plan 9 has dial[1] and friends, which kinda does to network connections what printf did for output. And, not surprisingly, something similar is in Go[2]. Of course, we're talking libraries here, so if you really want it in the language, then you're out of luck. Although any sufficiently advanced language should make this transparent enough anyway. [1]: http://swtch.com/plan9port/man/man3/dial.html http://swtch.com/plan9port/man/man3/dial.html [2]: http://golang.org/pkg/net/#Conn.Dial http://golang.org/pkg/net/#Conn.Dial
- azim 16y ago
  Java EE has something very similar to 0MQ in the form of JMS. I'm just throwing out something random here, but I imagine the reason no one else really does this in standard libraries is because it's quite complicated and can easily lead to fragile protocols. Take AMQP, for example, it took something like 5 years to agree on their 1.0 standard.
  - riffraff 16y ago
    and """ While iMatix was the original designer of AMQP and has invested hugely in that protocol, we believe it is fundamentally flawed, and unfixable. """
  - stcredzero 16y ago
    Java EE has something very similar to 0MQ in the form of JMS. I've worked with JMS, and no. Maybe my implementation was flawed. (Weblogic) IIRC, you needed 5 different objects of 5 different classes just to do anything.
  - phintjens 16y ago
    JMS does cover some of the same ground, all messaging does. But it's basically an API wrapper around two ancient technologies, a queue system and a topic system. I think it might have been IBM MQSeries (which became WebSphere MQ) and some other product but can't find the details. What JMS achieved was to somehow turn these two very different semantics into a single one, based around "destinations". That was very clever but also makes JMS weirdly complex to use because the queue (request-reply) pattern and the topic (publish-subscribe) pattern just don't work the same way. We designed AMQP originally by taking the JMS spec and reverse engineering that into a wire level protocol. Then around version 0.3 we threw out destinations and came up with a generic wiring model based on exchanges, bindings, queues. That was my summer holiday in 2005. AMQP is BTW still some way away from a 1.0 standard and mainly it's been five years trying to get reliability working in the center of the network. That always seemed destined to failure, as I explained in a presentation to the working group in 2006: http://www.zeromq.org/whitepapers:switch-or-broker http://www.zeromq.org/whitepapers:switch-or-broker. AMQP and JMS both focus on resources held in the center of the network. It's familiar to anyone using HTTP as their stack. Thin stupid clients talking to big smart servers. 0MQ turns the focus to smart clients working across a thin, stupid (but massive) network. Both approaches have their value. We (iMatix and the 0MQ community) tend to believe we can do a lot more, faster and more cheaply, using the distributed approach.
pjscott 16y ago
Then they'd better find a new rite of passage, because ZeroMQ is turning into a category killer.
- eps 16y ago
  So you are saying that the existence of a good library should discourage other people from writing their own? You are so missing the point.
  - sustrik 16y ago
    Did existence of TCP discouraged people to write their own implementation of OSI layer 4? Not really. But those who do so are a small -- i mean really small -- minority.

by eps 16y ago

stcredzero 16y ago

I don't understand why HLL don't have some sort of standard abstraction on top of sockets. Is it because it's a fundamentally "leaky abstraction" or should it be done? Seems to me that most HLL attempts to abstract networking try to be too high level.

mhd 16y ago
Plan 9 has dial[1] and friends, which kinda does to network connections what printf did for output. And, not surprisingly, something similar is in Go[2]. Of course, we're talking libraries here, so if you really want it in the language, then you're out of luck. Although any sufficiently advanced language should make this transparent enough anyway. [1]: http://swtch.com/plan9port/man/man3/dial.html http://swtch.com/plan9port/man/man3/dial.html [2]: http://golang.org/pkg/net/#Conn.Dial http://golang.org/pkg/net/#Conn.Dial
azim 16y ago
Java EE has something very similar to 0MQ in the form of JMS. I'm just throwing out something random here, but I imagine the reason no one else really does this in standard libraries is because it's quite complicated and can easily lead to fragile protocols. Take AMQP, for example, it took something like 5 years to agree on their 1.0 standard.
- riffraff 16y ago
  and """ While iMatix was the original designer of AMQP and has invested hugely in that protocol, we believe it is fundamentally flawed, and unfixable. """
- stcredzero 16y ago
  Java EE has something very similar to 0MQ in the form of JMS. I've worked with JMS, and no. Maybe my implementation was flawed. (Weblogic) IIRC, you needed 5 different objects of 5 different classes just to do anything.
- phintjens 16y ago
  JMS does cover some of the same ground, all messaging does. But it's basically an API wrapper around two ancient technologies, a queue system and a topic system. I think it might have been IBM MQSeries (which became WebSphere MQ) and some other product but can't find the details. What JMS achieved was to somehow turn these two very different semantics into a single one, based around "destinations". That was very clever but also makes JMS weirdly complex to use because the queue (request-reply) pattern and the topic (publish-subscribe) pattern just don't work the same way. We designed AMQP originally by taking the JMS spec and reverse engineering that into a wire level protocol. Then around version 0.3 we threw out destinations and came up with a generic wiring model based on exchanges, bindings, queues. That was my summer holiday in 2005. AMQP is BTW still some way away from a 1.0 standard and mainly it's been five years trying to get reliability working in the center of the network. That always seemed destined to failure, as I explained in a presentation to the working group in 2006: http://www.zeromq.org/whitepapers:switch-or-broker http://www.zeromq.org/whitepapers:switch-or-broker. AMQP and JMS both focus on resources held in the center of the network. It's familiar to anyone using HTTP as their stack. Thin stupid clients talking to big smart servers. 0MQ turns the focus to smart clients working across a thin, stupid (but massive) network. Both approaches have their value. We (iMatix and the 0MQ community) tend to believe we can do a lot more, faster and more cheaply, using the distributed approach.

pjscott 16y ago

Then they'd better find a new rite of passage, because ZeroMQ is turning into a category killer.

eps 16y ago
So you are saying that the existence of a good library should discourage other people from writing their own? You are so missing the point.
- sustrik 16y ago
  Did existence of TCP discouraged people to write their own implementation of OSI layer 4? Not really. But those who do so are a small -- i mean really small -- minority.