[zeromq-dev] Twisted integration, part 2: review
sustrik at 250bpm.com
Fri Jun 4 23:06:25 CEST 2010
>Some people might remember the twisted integration idea from a few
>weeks back, that kind of fizzled out for a bunch of reasons, the one
>that we can all help fix is a technical one. I've written a mail
>intended for the Twisted mailing list, and I was wondering if people
>could give it a quick review from the ZeroMQ side of things: I want to
>be sure I'm not misrepresenting or just plain lying about ZeroMQ.
>You can find the mail here: http://paste.pocoo.org/raw/221958/
I read your text.
I fully understand the "if it runs on top of TCP it's a TCP app"
approach. However, it should be pointed out that 0MQ works on top of
TCP, UNIX domain pipes, PGM reliable multicast, UDP (in form of
encapsulated PGM) and even inter-thread communication mechanism. This
makes it somehow more than a "TCP app".
On a different topic: I don't know whether twisted supports raw IP
sockets. If it does there's a similar problem there -- TCP is just an
app on top of IP, so why then support both?
I think POSIX got it right by using same API (Bekreley sockets) to access
different layers in the networking stack. Thus, you can use IP via POSIX
sockets as well as TCP. Hell, you can even send Etrhernet frames. The
fact that TCP is layered on top of IP and IP i layered on top of
Ethernet is not a problem. In the same way 0MQ can be (hypothetically)
accessed via Berkeley sockets. The fact that it's layered on top of TCP
Doesn't twisted subscribe to this "access any layer via single
Yet once more on a different topic: I still think creating a wrapper
library on top of 0MQ that would expose 0MQ via POSIX socket API would
solve lot of problems (including the twisted case) -- simply because 0MQ
sockets would become standard file descriptors, there would be no need
for 0MQ-specific zmq_poll, standard poll/select could be used instead
Am I still the only one who thinks this idea makes sense?
More information about the zeromq-dev