Re: [zeromq-dev] Valgrind warnings

[Oliver Smith]

On 6/13/2011 2:16 PM, Steven McCoy wrote:
> http://www.zeromq.org/docs:using-valgrind
>
My bad; I searched for zeromq "valegrind". Bleah :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Valgrind warnings

[Oliver Smith]

After adding ZeroMQ for tcp communication between some processes to help 
coordinate a test run, I started getting valgrind warnings as follows; 
unfortunately I haven't got time just now to look deeper...


   ==12019== Syscall param socketcall.send(msg) points to uninitialised byte(s)
   ==12019==at 0x4243A78: send (socket.S:100)
   ==12019==by 0x40DE4CC: zmq::ctx_t::send_command(unsigned int, zmq::command_t 
const&) (in /playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E687F: zmq::object_t::send_command(zmq::command_t&) (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E6B23: zmq::object_t::send_plug(zmq::own_t*, bool) (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E7A5F: zmq::own_t::launch_child(zmq::own_t*) (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40F07D9: zmq::socket_base_t::bind(char const*) (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40F7E07: zmq_bind (in /playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x80C7855: zmq::socket_t::bind(char const*) (zmq.hpp:259)
   ==12019==by 0x80DA56A: ZLogTest::Run() (testZLog.cpp:85)
   ==12019==by 0x809A4D7: TestUnit::RunTests() (testUnits.cpp:180)
   ==12019==by 0x809A8D4: main (testUnits.cpp:244)
   ==12019==  Address 0xbe947840 is on thread 1's stack
   ==12019==
   ==12019== Syscall param socketcall.send(msg) points to uninitialised byte(s)
   ==12019==at 0x4243A78: send (socket.S:100)
   ==12019==by 0x40DE4CC: zmq::ctx_t::send_command(unsigned int, zmq::command_t 
const&) (in /playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E687F: zmq::object_t::send_command(zmq::command_t&) (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E6AD3: zmq::object_t::send_own(zmq::own_t*, zmq::own_t*) 
(in /playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E7A6F: zmq::own_t::launch_child(zmq::own_t*) (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40F07D9: zmq::socket_base_t::bind(char const*) (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40F7E07: zmq_bind (in /playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x80C7855: zmq::socket_t::bind(char const*) (zmq.hpp:259)
   ==12019==by 0x80DA56A: ZLogTest::Run() (testZLog.cpp:85)
   ==12019==by 0x809A4D7: TestUnit::RunTests() (testUnits.cpp:180)
   ==12019==by 0x809A8D4: main (testUnits.cpp:244)
   ==12019==  Address 0xbe947844 is on thread 1's stack
   ==12019==
   ==12019== Thread 3:
   ==12019== Syscall param socketcall.send(msg) points to uninitialised byte(s)
   ==12019==at 0x4243A78: send (socket.S:100)
   ==12019==by 0x40DE4CC: zmq::ctx_t::send_command(unsigned int, zmq::command_t 
const&) (in /playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E687F: zmq::object_t::send_command(zmq::command_t&) (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E69BA: zmq::object_t::send_term_req(zmq::own_t*, 
zmq::own_t*) (in /playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E7B21: zmq::own_t::terminate() (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40F8AF4: zmq::zmq_connecter_t::out_event() (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E2B18: zmq::epoll_t::loop() (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40F3FF5: thread_routine (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x423BCC8: start_thread (pthread_create.c:304)
   ==12019==by 0x432069D: clone (clone.S:130)
   ==12019==  Address 0x57c25b4 is on thread 3's stack
   ==12019==
   ==12019== Syscall param socketcall.send(msg) points to uninitialised byte(s)
   ==12019==at 0x4243A78: send (socket.S:100)
   ==12019==by 0x40DE4CC: zmq::ctx_t::send_command(unsigned int, zmq::command_t 
const&) (in /playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E687F: zmq::object_t::send_command(zmq::command_t&) (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E698A: zmq::object_t::send_term(zmq::own_t*, int) (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E78C7: zmq::own_t::process_term_req(zmq::own_t*) (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E6F4E: zmq::object_t::process_command(zmq::command_t&) 
(in /playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E409E: zmq::io_thread_t::in_event() (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40E2B40: zmq::epoll_t::loop() (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x40F3FF5: thread_routine (in 
/playnet/wwiiol/lib/libzmq.so.1.0.0)
   ==12019==by 0x423BCC8: start_thread (pthread_create.c:304)
   ==12019==by 0x432069D: clone (clone.S:130)
   ==12019==  Address 0x57c2514 is on thread 3's stack
   ==12019==
   ==12019== Syscall param socketcall.send(msg) points to uninitialised byte(s)
   ==12019==at 0x4243A78: send (socket.S:100)
   ==12019==by 0x40DE4CC: zmq::ctx_t::send_command(unsigned int, zmq::command_t 
const&) (in 

[zeromq-dev] HWM/Swap refire question

[Oliver Smith]

What triggers the refire / draining of the HWM Swap? Is there a way to 
poke it?

If I create a simple client that sends console input to a simple server, 
and ctrl-c the server for a while, when it reconnects, it immediately 
gets the first few messages from the HWM (although sometimes it gets one 
less).

But the SWAP messages only seem to get transported as additional 
messages are pushed into the queue.

Is there any way to modify this behavior, as I can see a situation where 
a stall occurs;

+--  ++
  --sockA-->| Processor A |--sockB-->| ProcessorB |->-[ destination ]
  ^ +-+  +--+-+
  | v
  +

Re: [zeromq-dev] More x64 test numbers this time across box and alongside iperf

[Oliver Smith]

On 5/13/2011 3:25 PM, Christian Martinez wrote:


What I'm looking for is a feel for if these numbers are tracking as 
you'd expect. I've included iperf tests show you had another 
indication of network perf.



Also - failing any replies from someone with performance/tuning 
knowledge for the Windows build, Avocea/Evocosm have VS support, but I 
haven't looked at them in quite some time.


- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] More x64 test numbers this time across box and alongside iperf

[Oliver Smith]

On 5/13/2011 3:25 PM, Christian Martinez wrote:


c:\ZeroMq>local_thr.exe tcp://*: 40 500

message size: 40 [B]


For fullness of coverage, be aware that zmq_message_t has a built-in 64 
byte buffer to allow it to optimize small messages, I'd recommend 40, 
96, 128, 132 and 800 byte tests.



- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Just ran some tests with x64

[Oliver Smith]

On 5/13/2011 2:31 AM, Mikko Koppanen wrote:
>> Only problems I've seen with ZMQ under Windows, not x64 specific, are that
>> it can be a bit tricky to coerce into building as a static library rather
>> than a DLL
> Hi Oliver,
>
> we made a decision not to support static libraries under windows as we
> thought people don't have need for them. If this is a requirement I
> can look into fixing this.
For most cases, where ZMQ is being used for IPC and ITC, a DLL makes a 
lot more sense; but for components that are deployed in hostile 
environments, a DLL provides an additional attack vector ... and I'm not 
talking about trojans, I'm talking about the end-user running their own 
bit of code that uses OpenProcess -> VirtualAllocEx -> 
WriteProcessMemory to copy over a function that calls 
LoadLibrary("c:\myzmq.dll") -> CreateRemoteThread  :(

(I'm not giving anything away here ... google 'OpenProcess LoadLibrary' 
and break out the popcorn :(

We've *had* it working as a static library, but when we upgraded to 
VS2010 and Zmq 2.1.7 it broke, and I (being only a hobby Windows coder) 
haven't yet remembered that whatever I did to fix it before is in our 
SCCS repository. When I do, it'll occur to me it wouldn't be rocket 
science to fix it again, and maybe this time I can submit it as a patch ;-)


- Oliver
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Identities as cookies

[Oliver Smith]

On 5/13/2011 3:11 AM, Oliver Smith wrote:
I'm not sure I've 100% understood identities correctly, or maybe I 
have... I'd like to use identities as a sort of validated login cookie 
to make associating incoming data with a connection a wee bit easier, 
something like:
s/connection/authenticated and subsequently encrypted "session"/ && 
s/Thunderbird/bed/;



___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Identities as cookies

[Oliver Smith]

I'm not sure I've 100% understood identities correctly, or maybe I 
have... I'd like to use identities as a sort of validated login cookie 
to make associating incoming data with a connection a wee bit easier, 
something like:


import zmq ; zc = zmq.Context(1)

# Perform authentication.
sockAuth = zc.socket(zmq.REQ)
sockAuth.connect(authenticatorUri)
sockAuth.send(fancySchmancyEncryptedCredentials)
reply = sockAuth.recv()
sockAuth = None

if not reply or reply == "Go away":
# If this was real code, the message would be far sillier.
raise Exception("Login denied, or something. Possibly cake.")

# Obviously, sending the sessionId in plain text like this
# would be a bad idea, but I only want to write so much
# pseduo code. Writing comments, that I could do all day...
sessionId = reply.sessionId

# Now log in to the service.
sockSvc = zc.socket(zmq.XREQ)
sockSvc.setsockopt(zmq.IDENTITY, sessionId)
sockSvc.connect(reply.serviceUri)
sockSvc.send("Hello! You may recall me from such credentials as " + 
fancySchmancyEncryptedCredentials + random.random())
reply = sockSvc.recv()

if reply[:8] != "Biscuits":
raise Exception("Should have gone with the cake :(")

# I wish I hadn't opened with a mention of cookies...
return sockSvc, reply[8:]


If cookies work the way I think, the only issue with this would be the 
vulnerability to MITM injection?


If that's the case, my thinking is that the session ID + initial 
[encrypted, not clear] exchange would double as the initial 
application-level component for crypto seeding.


That would [effectively] prevent a different application instance or 
imposter or bug causing a different connection to correctly communicate 
as that identity, but would it also prevent the genuine application from 
re-establishing the same tcp connection in the case of intermediate 
network failure? e.g.


sock, seed = aboveCode()
sock.send(encryptedMsg)
system "ifconfig eth0 down"
sleep(30)
system "ifconfig eth0 up"
response = sock.recv()

If this is all sounding feasible...
- How would I poke ZeroMQ to give me a specific delivery tolerance?
sock.setsockopt(zmq.TIMEOUT, 30 * 1000)
- Is there a way to tell the XREP socket on the server to flush any 
backlog/close the underlying tcp socket associated with a particular 
identity?


serverSideSock = zc.socket(zmq.XREP)
...
def noMoreCakeFor(identity):
serverSideSock.setsockopt(zmq.DISCONNECT_IDENTITY, identity)

- Most importantly, where and how much overhead does the identity 
impose across a single ZMQ-hop?

client  server
   Is it only in the handshaking? Is it repeated periodically? Or 
is it a per-message overhead?


- Oliver



___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Just ran some tests with x64

[Oliver Smith]

On 5/13/2011 1:58 AM, Martin Sustrik wrote:
> On 05/12/2011 08:50 PM, Christian Martinez wrote:
>> Here you go Martin
> Thanks! I'll give it a look.
>
Wrong answer! "Get me a free VS2010 Ultimate with MSDN and I'll have it 
fixed stat" :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Just ran some tests with x64

[Oliver Smith]

On 5/11/2011 8:38 PM, Christian Martinez wrote:


Heh. Your guess is correct!

Followed the note on the site about how to build for x64 and just went 
with it. So far so good but was just wondering if anyone hit any snags.




Hi, Christian;

Only problems I've seen with ZMQ under Windows, not x64 specific, are 
that it can be a bit tricky to coerce into building as a static library 
rather than a DLL.


- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Trademark policy for 0MQ

[Oliver Smith]

Pieter Hintjens said the following on 5/12/2011 10:22 AM:

/Subject:/  ...*POLICY*/  .../

Pissy is fine.


=)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Problem with embedded ZeroMQ (static lib) under Windows

[Oliver Smith]

or, at least, it is when you build zeromq with
Properties -> General -> Character Set
set to Use Unicode Character Set.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Problem with embedded ZeroMQ (static lib) under Windows

[Oliver Smith]

On 4/29/2011 1:04 PM, Martin Sustrik wrote:

You mean the string returned by UuidToString?

The strange thing is that parameter is unsigned char rather than TCHUR
or alike.

However, existence of UuidToStringA and UuidToStringW seems to suggest
that the parameter is actually a TCHAR string.

In such a case just replace UuidToString by UuidToStringA and that
should do the trick.


   zmq::uuid_t::uuid_t ()
   {
RPC_STATUS ret = UuidCreate (&uuid);
zmq_assert (ret == RPC_S_OK);
ret = UuidToString (&uuid,&string_buf);

"string_buf" is an RPC_CSTR (const char*), UuidToString is #defined as 
UuidToStringW, which expects a wide string pointer...

- Oliver


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Problem with embedded ZeroMQ (static lib) under Windows

[Oliver Smith]

On 4/29/2011 2:20 AM, Pieter Hintjens wrote:
>> I've just updated our project's ZeroMQ to 2.1.6 from 2.1.0.
>>
>> We build zeromq as a static library and then embed it into the application.
>> (The only real trick to making this work was that the ZeroMQ headers
>> automatically go about using DLL_EXPORT if _WIN32 is defined).
>>
>> After the upgrade, we're running into a problem where zmq:connect() causes a
>> crash, which appears to be a Multi-Byte Character / Unicode conflict -- we
>> build our project (and our ZeroMQ) with Unicode.
> Did you make any changes to 2.1.0? The 2.1.6 package should be a drop
> in replacement, except for fixing a lot of bugs.
The only change was forcing the definition of DLL_EXPORT and DLL_IMPORTs 
to facilitate a static library.

The crash is basically caused by the forced casting to char* of the 
incoming string, which is actually being stored as wchar_ts. Thus 
instead of the UUID being  ... it is 
<0><0><0>...

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] I'm a coder, Jim, not an administrator...

[Oliver Smith]

Daniel Holth said the following on 4/28/2011 2:03 PM:
> Does 2.1.4 do anything for you? 
> https://launchpad.net/~chris-lea/+archive/zeromq 
> 
Actually, it does (thank you), but I was looking specifically for a way 
to install from a single local source build because, now I'll have to go 
off and figure out how to remotely add a PPA to ~70 installations :)

Pieter's answer is pretty much what I was expecting to have to do, the 
for host in `zmq-install-targets.py --ip` do ; scp ... blah ${host} ; 
done :)

I was just hoping that ... after all these years ... there'd be some 
magic in autoconf/autobuild tools that did that for ya :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Problem with embedded ZeroMQ (static lib) under Windows

[Oliver Smith]

I've just updated our project's ZeroMQ to 2.1.6 from 2.1.0.

We build zeromq as a static library and then embed it into the 
application. (The only real trick to making this work was that the 
ZeroMQ headers automatically go about using DLL_EXPORT if _WIN32 is 
defined).


After the upgrade, we're running into a problem where zmq:connect() 
causes a crash, which appears to be a Multi-Byte Character / Unicode 
conflict -- we build our project (and our ZeroMQ) with Unicode.


We're having a rather hard time figuring out how to fix this.

connect -> socketbase_t::connect -> socketbase_t::attach_pipes -> 
UUID() -> create_blob() -> convert_byte()


 App.exe!UUID::convert_byte(const char * hexa_=0x13915c19)  Line 
204C++

 App.exe!UUID::create_blob()  Line 213 + 0x10 bytesC++
>App.exe!UUID::UUID()  Line 34C++
 App.exe!socket_base_t::attach_pipes(zmq::reader_t * 
inpipe_=0x14a637d0, zmq::writer_t * outpipe_=0x14b70fb8, const 
std::basic_string, 
std::allocator > & peer_identity_={...})  Line 215 + 0x11 
bytesC++
 App.exe!socket_base_t::connect(const char * addr_=0x14df3070)  
Line 447 + 0x3e bytesC++
 App.exe!zmq_connect(void * s_=0x0f371bd0, const char * 
addr_=0x14df3070)  Line 366 + 0x11 bytesC++
 App.exe!ZMQ_Socket__connect__meth(lua_State * L=0x05516130)  Line 
2281 + 0x3f bytesC

 lua51.dll!1000896d()
 [Frames below may be incorrect and/or missing, no symbols loaded 
for lua51.dll]

 lua51.dll!10017f74()
 lua51.dll!100089eb()
 lua51.dll!10001fe5()
 lua51.dll!10007f9a()
 lua51.dll!10008b8e()
 lua51.dll!10002041()
 App.exe!_tolua_pushfieldusertype()  + 0x30 bytesC
 App.exe!_luaRunScript(lua_State * L=0x05516130)  Line 451 + 0x36 
bytesC++

 lua51.dll!10007f9a()
 lua51.dll!10008b8e()
 lua51.dll!10002041()
 App.exe!_tolua_pushfieldusertype()  + 0x30 bytesC
 App.exe!_luaRunScript(lua_State * L=0x05516130)  Line 451 + 0x36 
bytesC++

 lua51.dll!10007f9a()
 lua51.dll!10008b8e()
 lua51.dll!10002041()
 App.exe!_tolua_pushfieldusertype()  + 0x30 bytesC
 App.exe!_luaRunScript(lua_State * L=0x0551)  Line 451 + 0x36 
bytesC++

 msvcr90.dll!free(void * pBlock=0x967c93d3)  Line 110C
 8dff()

//
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] I'm a coder, Jim, not an administrator...

[Oliver Smith]

I need to upgrade a flotilla of internal testing machines (and virtual 
machines) running Ubuntu 10.10 to ZeroMQ 2.1.6, having to do it from source.

Trouble is that they don't have compilers on them, is there some way to 
easily generate some kind of remote installation bundle or package from 
the source tree? Or do I need to look at building my own dpkgs (a notion 
which fills me with fear and dread)?

I'm probably just going to copy the libraries and headers over to all of 
the machines, for now, but is there maybe a make install host=X option 
that would install to a remote-host destination?

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] "Who said that?"

[Oliver Smith]

Erh:
> cache = cacheForSrc[src]
 lastSrc = src
> doWork(msg, cache)


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] "Who said that?"

[Oliver Smith]

  
  
Martin Sustrik said the following on 12/21/2010 2:08 AM:
On
  12/20/2010 09:21 PM, Oliver Smith wrote:
  
  Martin Sustrik said the following on
12/17/2010 5:15 AM:

By bad data you mean malformed 0MQ
  frames? With 2.1 those are
  
  discarded silently and the connection is closed. We should
  also report
  
  the problem via sys://log.
  

No, it's probably data getting reused before it is transmitted -
i.e. my

issue, but it's very hard to track down because I don't know
which of

the many nodes is sending it :) The only way I can track that
down is to

send everything to separate ports and collate at the receiver,
until I'm

done debugging, and then reunify all of them again.

  
  
  Ok. So what's needed is message tracking for debugging purposes.
  Fair enough. So what about, for example, writing a simple wrapper
  over zmq_send() that would attach a message part containing
  identity of the particular node to every message?
  

Ah - I was arguing this particular incident as one of several
reasons why it might be beneficial to have access to the prior-hop
information above (i.e. in the application) the zmq_recv().

Another being WAN-transit cases where you do want to avoid exposing
any form of internal network-state information from the sender into
the packet beyond what is already deducible.

That is: you don't actually care what the IP address and port of the
last-sender/forwarder are, just that one is different than the
other.


[Image: An application calling recv() on a single zmq::socket which
is abstracting multiple bsd::socket or inproc sockets connected to
any number/type of sources]

Another use case: cache efficiency.

lastSrc = None
cache = None
while True:
    msg = zmqSock.recv()
    src   = msg.socketMuxDistinguisher()
    if src != lastSrc:
        cache = cacheForSrc[lastSrc]
    doWork(msg, cache)

    if itsTimeForACacheCheck():
        expireOldCaches()

It could be made exceedingly clear that this is NOT any form of a
source/return address by allowing the user to provide the local
distinguisher.

I'm not proposing, in any way or form, that this provide a value
that the user ever pass to any ZMQ function.



  

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] sending messages to a specific peer

[Oliver Smith]

mike castleman said the following on 12/20/2010 1:50 PM:
> One solution which may work is to use XREP/XREQ sockets: the client sets
> its identity on connect and then proceeds to ignore the usual REP/REQ
> pattern in favor of just waiting for messages from the server. A minimal
> implementation of this pattern (in Ruby) is at
> . This seems to work, but it also seems
> like an abuse of XREP/XREQ.

My understanding was that XREP/XREQ are basically abuse-friendly 
variants of REP/REQ, for exactly this kind of use case :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Session handling behind REQ/REP, etc.

[Oliver Smith]

I regularly requests for "how do I tell if ... disconnected" etc.

I'm currently struggling with a way to associate a message over a 
PULL/PUSH and/or REQ/REP multiplexed zocket with the previous hop so 
that I can locally associate incoming messages with cached data/etc, 
without needing to send that information as part of a message payload.

I wonder if these two seemingly unrelated issues could simply be handled 
by providing ZMQ with two additional setsockopts:

 struct userdata_t { } ;

 typedef userdata_t* (attach_fn)(void) ;
 socket_t { ...  setsockopt(zmq.ATTACHUSERDATA, attach_fn) ;  ... }

 typedef void (detach_fn)(userdata_t*) ;
 socket_t { ... setsockopt(zmq.DETACHUSERDATA, detach_fn) ; ... }

When ZMQ internally handles a new incoming connection and has finished 
with the tear-up process and is ready to begin receiving messages on 
said connection, it will call the registered attach_fn for that 
socket_t. Where possible, the user can either derive their user data 
class from userdata_t or else simply cast their data type to userdata_t.

When a connection terminates, the registered detach_fn is called with 
the user data. I can't decide whether it would be a good idea to allow 
this to happen regardless of the value of the user data: I can see use 
cases where you might just want to know when connections are lost 
without assigning userdata to them, in which case you might want your 
detach_fn called with NULL.

Example code:

struct Session : public zmq::userdata_t
{
 enum State { _Invalid, _Connected, _Authenticated } ;

 Session() : connectedAt(time(NULL)), state(_Connected), crypt() {}
 // The destructor could probably do something more...
 // such as send a fake "hangup" zmq::message_t downstream
 // if the sender has hung up unexpectedly, or put the session
 // onto an expiry queue yadda yadda..
 ~Session() {}

 time_t connectedAt ;
 State state ;
 EncryptionStuff crypt ;/// public/private keys for per-packet 
'cryption.

 bool authenticate(const zmq::message_t& msg) ;
 void process(const zmq::message_t& msg) ;
} ;

zmq::userdata_t* myAttachFn()
{
 Session* const session = new Session ;
 return (zmq::userdata_t*)session ;
}

void myDetachFn(zmq::userdata_t* session)
{
 if ( session == NULL ) return ;
 delete session ;
}

bool Session::authenticate(const zmq::message_t& msg)
{
 // First packet should contain "hello world"
 return ( strcmp((char*)msg.data(), "hello world") == 0 ) ;
}

void Session::process(const zmq::message_t& msg)
{
 switch ( session->state )
 {
 case_Invalid:
 // Session has gone bad, ignore it.
 return  ;
 break ;
 case_Connected:
 // This is the first message from this connection.
 if ( session->authenticate(msg) )
 state = Session::_Authenticated ;
 else
 state = Session::_Invalid ;
 break ;
 case _Authenticated:
 printf("%s\n", (char*)msg.data()) ;
 break ;
}

int main(const int argc, const char* const argv[])
{
 zmq::Context_t c(1) ;
 zmq::socket_t s(c, zmq::PULL) ;

 s.bind("tcp://0.0.0.0:54321") ;

 s.setsockopt(zmq.ATTACHUSERDATA, myAttachFn) ;
 s.setsockopt(zmq.DETACHUSERDATA, myDetachFn) ;

 while ( true )
 {
 zmq::message_t msg ;
 s.recv(msg) ;

 Session* const session = (Session*)s.getUserData() ;
 // or msg.getUserData?

 assert( session != NULL ) ;// 
how could it be?

 session->process(msg) ;
 }
}

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] "Who said that?"

[Oliver Smith]

Martin Sustrik said the following on 12/16/2010 6:41 AM:
>
> There's no API to get sender's address. The reason is that in multi-hop
> scenarios is not even clear, who's the sender: The original sender or
> the device at the last hop?
I'm not actually looking for the sender's address so much as who */I/* 
got the message from, IE the previous hop. While the address and port 
would be nice for diagnosing sources of bad data within a fabric (I 
spent 2 days this week tracking down what turned out to be a bad stick 
of ram in a machine corrupting outgoing data), it could be any 
thread-unique value that discretely identifies a given TCP-socket-pair 
connection to this zmq context.

Consider:

 p = sock.recv()
 if p.previousHopID() in sessions:
 p = decrypt(p, sessions[p.previousHopID].encryptionStuff)
 p = process(p)
 sock.send(p)
 else:
 session = Session(p.previousHopID())
 sessions[p.previousHopID()] = session

 sock.setsockopt(zmq.SENDMORE, True)
 sock.send(encrypt(salt, server.encryptionStuff))
 p = process(p)
 sock.setsockopt(zmq.SENDMORE, False)
 sock.send(p)

Note carefully: If the previousHopID() was the IP/port, you could easily 
get confused when a node behind NAT disconnects and another node 
subsequently connects with the same NATed ip/port.

> However, with XREQ/XREP sockets the identites of individual hops are
> aggregated in the request (as initial message parts). Check the guide
> for details.

As I said - I can't put the ID information in the WAN packets.

I just have to not use ZMQ for the WAN transit. I'm using a half-baked 
little ZMQ->TCP->TCP->ZMQ bridge for now.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] "Who said that?"

[Oliver Smith]

Trying to re-remember how to obtain the return address for a given ZMQ 
message, or the ZMQ representation thereof (a UUID or something). The 
message originator might be behind a NAT system, so the originating 
address could be useless (there are too many 192.168.0.1s in the world).

What I want to know is, where does the ZMQ interface I got this message 
from think it came from? So that I can distinguish messages from 
different incoming streams behind the multiplexed socket I'm talking to.

Consider the following pseudo code:

 msg = interface.receive()
 user = userLookup(msg.streamIdentifier)
 if user:
 user.handle(msg)
 else:
 loginOrGTFO(msg)

I realize I could just slap some kind of GUID into the payload, but in 
these particular message streams, bits are at a premium.

I recognize that the sender address/port in an IP packet should never be 
trusted any more than the words "PRIORITY MAIL" or "YOU'VE WON 
$10,000,000!" on a physical envelope, however in my particular use case 
- and for similar reasons - it makes an excellent starting point.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Logging format for sys://log transport

[Oliver Smith]

Martin Sustrik said the following on 11/19/2010 4:55 AM:
> I think there are many possible audiences, however, we haven't yet
> figured out who exactly is it going to be.
>
> Thus, the whole system should be open-ended allowing for later addition
> of functionality. That's why I alluded to /proc pseudofilesystem.
I would caution against this approach. If you try to please everyone, 
you will require a great deal of description for each log message. The 
logging requirements from a developer are likely to be different than 
those of a sysadmin or a debugger or a user, both of whom are going to 
want different ways of artefacting any given log message.

Here is my $0.02. More than anything else, make the ZeroMQ logging 
assist with developing a ZeroMQ tool, and leave the downstream reportage 
to the application developer.

It wants to provide a way for the ZeroMQ team *and* the application 
developer to locate a point of failure in the ZeroMQ source, and having 
a logging entry with the file/line of the report is somehow mentally 
more conducive to your going and looking at that piece of code than some 
random message (after a few years of working with other people's code, 
you rapidly learn that searching for any given text string in 
someone-elses-code is going to be the start of a really lousy day).

The temptation to develop a new logging system will be strong. I'm 
pretting sure that logging leads directly to suffering without the 
intermediate steps of fear, anger and hate :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Logging format for sys://log transport

[Oliver Smith]

I would like to pose a question here: who is the target audience the 
sys://log transport?

"syslog" is primarily intended for system administrators. But it seems 
like sys://log is more of a debug trail for programmers.

Among many excellent designs by my predecessor here was our product's 
logging system "dbugLog" which, although a little verbose, has 
continually proven invaluable for diagnosing complex interactions across 
a series of distributed processes.

The format is:

LEVEL [TIMESTAMP SOURCEFILE:LINENO] MESSAGE

The []s are literals, there to help with stripping that information out 
with awk/perl/etc.

E.g.

I [20101116-12:21:13.399.221 zmqSend.cpp:112] Connection opened

We have a normalized convention of beginning "message" with a set of 
key:value pairs that distinguish attributions such as ... which 
"teulIndex" (our internal socket API), which user, etc.

I [20101116-12:21:13.399.221 login.cpp:875] t:2231 p:10502 c:oliver 
login granted

I've now started using zmq to log these messages and altered the format 
a little,

LEVEL|FACILITY|TIMESTAMP|SOURCE:LINE|ATTRIBUTIONS|MESSAGE|[BACKTRACE]

I've worked with a lot of distributed systems in the last ~20 years, but 
it has been a wonderful experience being able to rely so heavily on the 
logs.

The inclusion of __FILENAME__ __LINENO__ in the logs has the convenience 
of tying in nicely with various IDEs which can be coaxed into receiving 
a quick rework of the logs into an errors list and give you a guided 
tour of the program flow... Mmm...

This may be more complex than ZMQ needs, but I wanted to put it out 
there as food for thought.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ vs TCP sockets - survey

[Oliver Smith]

Pieter Hintjens said the following on 10/26/2010 3:56 PM:
> Hi y'All,
>
> As a kind of a survey / test to see if you're awake, I'd like to
> solicit your views, as 0MQ users and contributors, about the most
> significant differences between 0MQ and traditional TCP sockets.  I.e.
> how would you convince your boss that it was worth using 0MQ rather
> than just coding your app the old fashioned way...?
>
> Feel free to +1 / 'this' other people's comments so we know what
> tickles you the most.  I'll collect the results in a comparison
> document on the wiki.
Not wanting to sound negative, but would it perhaps be worth fielding 
the counter question: why not?

(For me, the main thing keeping me from pushing ZeroMQ on our project is 
the encryption issue, and a lack of time to investigate it fully myself 
right now)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] c++ api issues

[Oliver Smith]

  Martin Sustrik said the following on 10/20/2010 7:09 AM:
> I see no real way out.
> However, what you can do is to write a simple wrapper that would use
> zmq_msg_copy in copy constructor and provide that to be used by those
> who care about storing messages in containers more than about extreme
> performance.
*Sniff* I smell a move constructor/assignment :)
http://msdn.microsoft.com/en-us/library/dd293665.aspx


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] shutdown mutex issue with 2.10

[Oliver Smith]

  Martin Lucina said the following on 10/14/2010 11:41 AM:
> This is all in the pipeline but the only person with enough zmq-core-fu to
> implement it is probably Martin Sustrik :-)
Who is truly a god amongst mortals :) <3 Martin :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] shutdown mutex issue with 2.10

[Oliver Smith]

  Pieter Hintjens said the following on 10/14/2010 12:18 AM:
> Oliver,
> Sounds like the same issue as:
>
> http://github.com/zeromq/zeromq2/issues#issue/85
> http://lists.zeromq.org/pipermail/zeromq-dev/2010-October/006607.html
Actually, I appear to have demonstrated two problems in one go.

In my sample code, I ran into the problem with untransmitted data 
hanging an application above main trying to send data that will never be 
received.

But in my original code I appear to be running afoul of a problem with 
destructor ordering.

My zmq::context_t (static) is having it's destructor called before my 
zmq::socket_t (new'd), resulting in the context waiting forever when the 
application terminates.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] shutdown mutex issue with 2.10

[Oliver Smith]

  On 10/14/2010 1:33 AM, Martin Sustrik wrote:
> It's a different scenario. Oliver has a pending message that waits to be
> sent.
>
> Issue 85 has to do with a socket that haven't been closed.
Hmm - well, in that case, my attempt to duplicate the issue I'm having 
failed.

The origin of my problem is that my unit tests are randomly hanging 
after exit. All of my sends and receives are very carefully matched, or 
else the unit tests themselves would fail.

How do I cancel all pending, outgoing messages?

If there is no way to do this, then ZeroMQ 2.1 is essentially /broken/ 
for everything except 'C' since the application will hang outside of the 
programmer's control (above main()). And you've created a situation 
where flow control is impossible; if I'm communicating with a thread 
that crashes or tells me it's shutting down, well it's already too late 
- I already put stuff on the send queue.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] shutdown mutex issue with 2.10

[Oliver Smith]

  Recently upgraded from an earlier 2.x (2.0.7 I think) to 2.1.0. I 
immediately ran into an unusual problem under Linux where my unit test 
module passed all tests but then failed to terminate.

The test unit keeps getting stuck with this backtrace, apparently in the 
destructor for a static zmq::context being destroyed at shutdown.

0xb7fe2430 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fe2430 in __kernel_vsyscall ()
#1  0xb7da9af9 in __lll_lock_wait () at 
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:142
#2  0xb7da513b in _L_lock_748 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xb7da4f61 in __pthread_mutex_lock (mutex=0x806a040) at 
pthread_mutex_lock.c:61
#4  0xb7f0716a in zmq::ctx_t::terminate() () from /usr/lib/libzmq.so.0
#5  0xb7f22691 in zmq_term () from /usr/lib/libzmq.so.0
#6  0x08059413 in ~context_t (this=0x806a008, __in_chrg=) 
at /playnet/wwiiol/include/zmq.hpp:178
#7  0x0805a924 in ~Fnar (this=0x80697dc, __in_chrg=) at 
wwii/wwiiZMQ.cpp:12
#8  0xb7c721bf in __run_exit_handlers (status=0, listp=0xb7d99324, 
run_list_atexit=true) at exit.c:78
#9  0xb7c7222f in *__GI_exit (status=0) at exit.c:100
#10 0x0805714c in main (argc=1, argv=0xbfffee64) at tests/testUnits.cpp:241

You can replicate the issue with the following code:


// Demonstrates zmq hang on static destructor.

#include
#include
#include
#include
#include

// Static context: created on startup.
static zmq::context_t staticContext(1) ;

// Wrapper for 'free' for strdup'd message_t.
static void freepayload(void* data, void*)
{
 free(data) ;
}

// Send a text string using strdup to copy the string.
static void send(zmq::socket_t&  socket, const char* const text)
{
 zmq::message_t msg(strdup(text), strlen(text) + 1, freepayload) ;
 socket.send(msg, ZMQ_NOBLOCK) ;
}

// To ensure that the inner zmq::context_t is destroyed well
// before the static one, wrap the code to be tested here.
// This also helps isolate the static context_t as the cause,
// by verifying we were able to leave this function.
void fn()
{
 // locally scoped context to be destroyed when we exit fn().
 zmq::context_t innerContext(1) ;

 // Bind a socket on it.
 zmq::socket_t is(innerContext, ZMQ_PULL) ;
 is.bind("tcp://127.0.0.1:12345") ;

 // verify we can't receive anything.
 zmq::message_t msg ;
 if ( is.recv(&msg, ZMQ_NOBLOCK) )
 {
 printf("error: should not have received from is\n") ;
 }

 // now bind a receiving socket
 // **BINDS TO THE STATIC CONTEXT, NOT LOCAL CONTEXT**
 zmq::socket_t os(staticContext, ZMQ_PUSH) ;
 os.connect("tcp://127.0.0.1:12345") ;

 // send a message between contexts.
 send(os, "hello") ;

 // record that we're leaving this function.
 printf("reaching end of function\n") ;
}

int
main(int argc, const char* const agv[])
{
 printf("calling fn\n") ;

 fn() ;

 printf("returned from fn\n") ;

 exit(0) ;
}


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] using 0MQ in a MMORPG online game.

[Oliver Smith]

  kasicass said the following on 9/3/2010 8:56 AM:
> Aha, your solution is great. I will try.
>
> I've use libevent for it right now, and it works perfectly.
>
You may want to look at Jenkins Softwares' RakNet 
http://www.jenkinssoftware.com/ - he's done much of the work necessary 
for the client-facing stuff, including object replication etc.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Encryption (OpenSSL/TLS)

[Oliver Smith]

 Martin Sustrik said the following on 10/1/2010 1:03 PM:

You've got me wrong. I was not objecting against SSL. What I said was
that the message level encryption would have to be implemented later on
anyway, so we'll do the work twice.
Can I suggest that this is actually true both as you describe/ and/ 
because of the duality of ZeroMQ (Parallelism/Networking). I'm not 
talking about people being lazy and wanting to use one listener for both 
purposes (which I would probably be guilty of, but I do not deign to 
defend or use as a rationale for a decision on this issue) but for 
situations where developers use ZeroMQ across a large project for both 
purposes for convenience. So where they use 0MQ for performance message 
passing/parallelism within their server fabric and may need 
message-level encryption for intra-site communications and 
internal-attack prevention, they would probably prefer TLS encryption 
for edge communications, and tunneling may not be an option if those 
edge communications are end-user facing.


- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Encryption (OpenSSL/TLS)

[Oliver Smith]

  Burak Arslan said the following on 10/1/2010 2:41 AM:
> in short, once 0mq gets robust enough to survive outside the corporate
> firewall, it's secure enough for its purposes. any other security
> precaution should be implemented on top of it, via message signcryption.
One major advantage to message-level encryption would be the option to 
mix a stream.

For example, consider the following stream:

  Authentication
 --->
 Acknowledgement
<---
 Request
 --->
 Response
<---
   {Time}
 Ping
--->
Pong
   <---


Being able to be discriminatory about when encryption is employed might 
be beneficial (of course, it might also lead to really bad practices ;)

- Oliver


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Encryption (OpenSSL/TLS)

[Oliver Smith]

  Pieter Hintjens said the following on 10/1/2010 3:17 AM:
> Do we need to stretch an encrypted connection over arbitrary devices?
> I'm not sure that's the real use case.  What I see is that unsecured
> 0MQ networks need encryption at the edges, where they speak to
> external clients.
Exactly - but as Matt points out, it needs to be made blaringly clear 
that this is for when ZeroMQ is operating as a networking API and not as 
a parallelism API.

TLS would seem to work really well for this because - like ZeroMQ - it 
provides an endpoint replacement system (instead of a FILE* you use a 
BIO* or something, in the 2 days since I looked at it my brain has 
"recovered" from the experience by eliminating almost all traces ;)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Encryption (OpenSSL/TLS)

[Oliver Smith]

  Martin Sustrik said the following on 10/1/2010 1:11 AM:
>> The only
>> downside of this approach is that that each network hop will have to
>> encrypt/decrypt the message.
> That's exactly the point IMO. It means that each intermediary box
> (device) would have to be trusted. Doing it that way you would basically
> disable using 0MQ as internet-scale fabric.
No, it is just the wrong way to use 0MQ as internet-scale fabric.

In my particular current use case, I am considering placing 0MQ as a 
communications medium between several server processes, where there is 
no need for security between machines. But I then want to expose access 
to some of this to the externally run client. I want those connections 
to be encrypted.

I really don't feel like being the first MMO to have our customers 
launch OpenVPN in order to play the game ;)

The TLS solution works exceptionally well in these cases precisely 
because I could build a configuration such as:

  ++
  | Public |
/-+   +-+| Facing |
| |   | || Server |
| Clients | --+ TLS +-->  ++
| |   | {io}|| ZeroMQ |
+-/   +-+| Device |
  ||
  ++---+
   |
   v
  ++
  | Server |
  ++
   ^ /---+
   | | Internal  |
   +-=---| Server|
 | Processes |
 +---/

The Device would communicate to remote clients over encrypted sockets, 
e.g. tcps://*:1234/, but communicate on to the server via whatever 
protocol you choose.

Just another task successfully offloaded by ZeroMQ :)

- Oliver
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Encryption (OpenSSL/TLS)

[Oliver Smith]

  Pieter Hintjens said the following on 9/30/2010 1:49 PM:
> Hi Oliver,
>
> Mato and I were discussing this exact topic yesterday.  Neither of us
> are really security experts but his experience trumps mine.  I'd go
> for an OpenSSL TLS transport layer that replaces the existing tcp://
> transport.  Mato's opinion was that this would not work, and the
> correct approach would be per-message encryption, with out of band key
> exchange using some existing technology.
>
> Mato's approach has the advantage of also giving secure multicast.
>
> -Pieter
Hmm.

I'd also thought about using something like "tcps://" for an underlying 
"secure connection" transport, I hadn't thought about multicast.

What was Matos reasoning for saying it would not work? Is it to do with 
provisioning keys etc?

The reason I think that a ZeroMQ socket-type level would work best is 
that you would then be able to do:

 # Context
 ctx = zmq.Context(4)
 # Incoming socket
 s = ctx.socket(zmq.REP)
 # Public interface
 s.bind("tcps://*:1234")
 # Private local interface
 s.bind("tcps://192.168.0.1:1235")

 while True:
 msg = s.recv()
 result = process(msg)
 s.send(result)

Of course, somewhere in there I need to tell it where my encryption 
stuff is... Surely that could be done with something like

 s.setsockopt(zmq.TCPS_CONFIG_FILE, "/etc/myserver.xml") or 
"/etc/myserver.json" or .txt or whatever


- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Encryption (OpenSSL/TLS)

[Oliver Smith]

  After a little time off doing other stuff, I come back to my guerrilla 
ZeroMQ integration project. An early concern for my project is security, 
and it seems like using OpenSSL's TLS API might provide a 
wheel-reinvention-avoiding means of encrypting the streams. But it seems 
like I'd have to integrate it very much at the zmq::socket_t level or 
else I'd have to do per-message_t encryption which doesn't seem terribly 
efficient.

If anyone has any pointers on encryption w/ZeroMQ ... be really, really 
greatful :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Client Server Model in Python

[Oliver Smith]

Oliver Smith said the following on 8/24/2010 12:29 PM:

Abhishek K said the following on 8/24/2010 12:00 PM:

The method I was looking for was

class Extended_thread(Threading.thread):
def run(a)
  #some logic

context=zmq.Context()
socket=context.socket(zmq.REP)
socket.bind('tcp://127.0.0.1: <http://127.0.0.1:/>')
while True:
message=socket.recv()
   new Extended_thread(socket)


Wait - that's creating a new thread for every message you receive. 
That's going to be incredibly expensive.
What you actually need, apparently, is a zmq_device. I'm not sure how 
you do that in Python.


Again, I think this is another example for the case where it should be 
allowed to bind multiple times to an address over the same context, so 
that multiple threads can service a single port, e.g.


ctx = zmq.Context(1)
workers = []

def createThreads(numThreads, endpoint):
global ctx, workers
for i in range(0, numThreads):
sock = ctx.socket(zmq.REP)
sock.bind(endpoint)
thread = new Extended_thread(sock)
workers.append(thread)

You can do this with a device, but if you're going to be doing it all 
over a single context, it just seems like so much cpu wastage :)
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Client Server Model in Python

[Oliver Smith]

Abhishek K said the following on 8/24/2010 12:00 PM:

The method I was looking for was

class Extended_thread(Threading.thread):
def run(a)
  #some logic

context=zmq.Context()
socket=context.socket(zmq.REP)
socket.bind('tcp://127.0.0.1: ')
while True:
message=socket.recv()
   new Extended_thread(socket)


Wait - that's creating a new thread for every message you receive. 
That's going to be incredibly expensive.


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Client Server Model in Python

[Oliver Smith]

Abhishek K said the following on 8/24/2010 8:05 AM:

Hi

I am new to ZeroMQ
I am using a Client Server Model in Python.
This is the basic outline of the server code.

context=zmq.Context()
socket=context.socket(zmq.REP)
socket.bind('tcp://127.0.0.1: ')
while True:
message=socket.recv()
if message[:2]=="01":
##logic1
if messafe[:2]=="02":
  ## logic 2

socket.send(response)


I have 2 questions,

* I think the if the message processing logic takes lot of time,
  how can I thread the process of processing the message (in Python)
* I need to send an options along with the message, currently I am
  sending the options as the first  2 characters of the message.
  (message[:]). Is there a better way provided by ZMQ.

Bear in mind that Python's default threading system isn't true 
threading... Your first option might be to create separate threads with 
different endpoints for different message types. You could maybe look at 
Stackless python for the threading.


You could use the multipart message scheme for splitting the options 
from the message, and then use a lookup table to decide what function to 
call to process the second half of the message.


handlers = {
'01' : handle01
,'02': handle02
...
}

def handle01(msg):
...

def handle02(msg):
...

main():
...
msg = sock.recv()
prefix = msg[:2]
if not prefix in handlers:
error(msg)
else:
handlers[prefix](msg[2:])

- Oliver


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Announcing ZFL

[Oliver Smith]

On 8/21/2010 12:57 PM, Pieter Hintjens wrote:
> Multiplexing across TCP connections, right?
>
> You could use names rather than numbers for the substream.  That gives
> you a naming flexibility similar to what we have with inproc/ipc, and
> possibly some kind of service abstraction without a name service.
>
Also in-keeping with zeromq's use of URLs.

 tcp://foo:1234:232
looks weird compared to
 tcp://foo:1234/bar

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Announcing ZFL

[Oliver Smith]

 Style question:

For the most part, you've used stroustrup formatting with braces 
outdented on their own line, e.g.


static int
s_private_function_example (void)
{

the first struct in zfl_base.c uses K&R/GNU style:

struct _zfl_base_t {
int
filler
};

I'm personally a fan of stroustrup style because, for the cost of a few 
extra lines here and there, you get one-shot visual scanning compared to 
the diagonal/across-down scanning with K&R.



<>___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Can't bind same ZMQ_UP/DOWNSTREAM multiple times.

[Oliver Smith]

  On 8/19/2010 5:10 PM, Jon Dyte wrote:
> does this do what you want
Yes :) Perfectly, thank you.

It still seems like a duplication of work resulting from an artificial 
imposition of an unrelated networking constraint.

That is: because the networking concept of bind and connect, server and 
client are being strictly enforced, you need an /additional worker/ (the 
device) to bridge two communications channels that are only separated by 
that imaginary concept.

If the zmq_contexts were to ALWAYS take ownership of bound sockets and 
then quietly join binders to them, then you could always have multiple 
binds to an address regardless of protocol. You would, of course, not be 
able to bind the same address across different contexts, but that then 
begins to make sense.

 ctx1 = zmq.Context(1)
 ctx2 = zmq.Context(2)

 s11, s12, s21 = ctx1.socket(zmq.DOWNSTREAM), 
ctx1.socket(zmq.DOWNSTREAM), ctx2.socket(zmq.DOWNSTREAM)
 addr = "inproc://address"
 s11.bind(addr)# ctx1 now owns the address.
 s12.bind(addr)# OK: Context owns the address.
 s21.bind(addr)# FAIL: Address already in use.


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Assertion failure in pull.cpp

[Oliver Smith]

  On 8/20/2010 11:37 AM, Pieter Hintjens wrote:
> OK, I was using the wrong socket (!) in one of the test steps, which
> explains most of the problems I was seeing.  If one connects A rather
> than B, it's normal that writing to B won't do much.
*GRIN* Honestly - I keep running into the same thing every time I start 
a new up/downstream pair. Caveat: Because I was part of the discussion 
on the naming, I actively think "don't get this the wrong way around" 
and proceed to do exactly that :)

Again, I think this is a good case for having some debug-level warning 
mechanism where zeromq can provide more feedback when compiled with 
-DEBUG or something.

You'd have two copies of the zeromq library on your system, libzmq.a and 
libzmqdebug.a ... the options to build the latter would turn on the 
warning feedback system, so that more verbose output could be supplied 
when these kinds of issues occur. Great help for beginners and old hands 
alike.

m...@mine$ ./testapp
Assertion failed: inpipe_ && !output_ (pull.cpp:39)
m...@mine$ wtf?
Command 'wtf' not found.
m...@mine$ g++ -o testapp testapp.cpp -lzmqdebug
m...@mine$ ./testapp
testapp.cpp:35: Error: called recv() on a read only socket (type: 
ZMQ_DOWNSTREAM)
Assertion failed: inpipe_ && !output_ (pull.cpp:39)
m...@mine$ thanks!
Command 'thanks' not found.


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Can't bind same ZMQ_UP/DOWNSTREAM multiple times.

[Oliver Smith]

Jon Dyte said the following on 8/19/2010 3:11 PM:
> I'm reading this thread late on, but isn't this what the streamer is
> for, assuming it is a pipeline, not req-rep?
>
> so if you have 3 threads producing data and and 6 threads doing
> subsequent work (that was the jpg attached earlier in the thread)
>
> don't you just need to put a streamer inbetween ?
>
> so the 3 producers connect to the streamer and write to it, and the 6
> workers connect and read from it
>
> so 10 threads in this example?
>

Does the streamer handle inproc:// ?

- Oliver
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Can't bind same ZMQ_UP/DOWNSTREAM multiple times.

[Oliver Smith]

Martin Sustrik said the following on 8/19/2010 7:19 AM:
> Binding several sockets to a TCP port to get a multicast delivery is
> something TCP doesn't support. You'll either have to do with a device in
> the middle or use IP multicast (via PGM) which effectively turns your
> switch into the device. Using IP multicast has its own set of problems
> though.
>
I understand the TCP component there, but again: ZeroMQ sockets aren't 
sockets.

a/ I was trying to use inproc://
b/ All of my attempts to service the socket are on the same context.

Currently the pipeline pattern allows you to connect 1-N, but it doesn't 
let you connect N-to-N because of a TCP issue?


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Can't bind same ZMQ_UP/DOWNSTREAM multiple times.

[Oliver Smith]

  On 8/17/2010 1:43 PM, Oliver Smith wrote:
> In the context of up/downstream, I want the /context/ to take the 
> connections and fair-queue messages between the consumer threads.
Ergo:
 newbind(address)
 {
 int rc = aquireAddress() ;// Calls bind() if this 
context doesn't already own the address.
 if ( rc != 0 ) return rc ; // Probably EADDRINUSE
 return connect(address) ;
 }

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Can't bind same ZMQ_UP/DOWNSTREAM multiple times.

[Oliver Smith]

 On 8/17/2010 4:02 AM, Pieter Hintjens wrote:

Well, the question makes more sense now but (excuse my poor tired
brain), there are still aspects escaping me.

Do you want the second thread to take over the socket?  Do you want to
fair-share incoming connections so that one thread gets half of the
connections, and the second thread the other half?  Do you want each
thread to get all the connections but then fair-queue messages between
the two threads?
In the context of up/downstream, I want the /context/ to take the 
connections and fair-queue messages between the consumer threads.

And, sorry to be stubbornly stupid, I still don't see why you actually
need to reuse the same address rather than a second one.

Oliver, could you explain what semantics you expect by "multiple
threads servicing the same socket?"
I have two groups of threads either side of a connection. Maybe its 4 on 
the left and 16 on the right, or maybe 16 on the left and 4 on the 
right. Maybe it's dynamic.


Problem is, someone has to bind the address for anyone to be able to 
talk to it.


See the attached diagram (sorry for slopping drawing, no mouse :-)

Circles = endpoints, oblongs = workers.

Right now, to implement the "mid" endpoint, you either need a device or 
a device-like concentrator (a worker that binds an address and allows 
the workers on the right to connect to it, and then forwards messages 
from the left to the right).


Which is, essentially, duplicating lots of work.

- Oliver

<>___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Newbie Bait Request: Debug "Warning" mechanism.

[Oliver Smith]

Might it be a good idea to introduce a warnings system into the ZeroMQ 
debug-build flavor.

debugWarn(ZMQ_WARNING_33) ;// ZeroMQ Caution #33: Application called recv() 
on a ZMQ_SUB socket without subscribing to any topics. (See zmq_setsockopt).

if ( settingSockOptZMQ_SERIALIZE_FUNCTION and context.numThreads<= 1 )
debugWarn(ZMQ_WARNING_34) ;// ZeroMQ Caution #34: Consider using more 
than one IO thread in applications which may have to serialize data to maintain 
throughput (see zmq_init)

etc.

Perhaps coupled with a sock-opt for disabling a particular warning - e.g. if 
your recv() is waiting for a term;)

- Oliver


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Can't bind same ZMQ_UP/DOWNSTREAM multiple times.

[Oliver Smith]

  On 8/16/2010 12:07 PM, Pieter Hintjens wrote:
> Hi Oliver,
>
> I can repeat my previous reply.  After reading your email I still
> don't understand why you need to bind to the same endpoint twice, and
> why you expect this to work (it won't).
>
> You cannot bind two sockets to a single endpoint.  It's not a legal semantic.
>
> So what in fact is your question?  Sorry if I missed it.
I did do a good job of making that a bit hidden.

The question: What is the right pattern for doing this -- 1 -> N -> M -> 
1 four stage parallelism.

Why it's even a question: Remember, "ZeroMQ sockets aren't /sockets/". 
That just happens to be one of the underlying mechanisms.

 From a networking perspective, I understand why multiple binds don't 
work. And setting SO_REUSEADDR would just be messy...

But I would have thought that internally if multiple socket_ts tried to 
bind to the same IP socket address ///via the same context/// you would 
have handled that internally the same way that you handle multiple 
connects: thus allowing multiple threads within an application to 
service the same socket.

Consider:

8x--- snip ---x8
import zmq
import re

ctx = zmq.Context(8)

class HTTPWorker(threading.Thread):
 def __init__(self):
 threading.Thread.__init__(self)
 self.daemon = True
 self.sock = ctx.socket(zmq.REP)
 self.sock.bind("tcp://0.0.0.0:80")

 def run(self):
 urlMatch = re.compile(r'^GET\s+([/a-zA-Z0-9_.%-]+)')
 while True:
 msg = self.sock.recv()
 matches = urlMatch.match(msg)
 if matches and matches.group(1):
 content = readFile(matches.group(1))
 reply = headers(matches.group(1), content)
 self.sock.send(reply)
8x--- snip ---x8

This would allow one processes to have multiple threads servicing a 
single TCP socket endpoint without the need to go through a device or 
have the operator fork multiple processors.

I do absolutely understand why "self.sock.bind(same address multiple 
times)" on a single machine does not work. But that requires the 
end-user to be aware of the underlying network basis of the function of 
"bind".

Now consider:

 # X threads are going to receive transparently
 # multiplexed work from Q sources.
 self.workin = ctx.socket(zmq.DOWNSTREAM)
 self.workin.connect("inproc://stage1-worker")

 # Those X stage1 workers are going to forward
 # additional work to Y transparently
 # multiplexed stage 2 workers.
 self.workout = ctx.socket(zmq.UPSTREAM)
 self.workout.bind("inproc://stage2-workers")

Again -- I understand why, under the hood, BSD's bind(3) function 
returns address already in use.

But I'm not using bind(3), I'm using zmq->context->bind. Therefore the 
answer to the question should be in ZeroMQ context terms and not 
sockets-api terms... If the answer was "because they are using different 
contexts, and only one context can bind to a socket address" - that 
would work. But "only one endpoint can bind to a socket address even on 
the same context as the other endpoint" doesn't... Certainly not in many 
sample use cases.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Can't bind same ZMQ_UP/DOWNSTREAM multiple times.

[Oliver Smith]

  On 8/16/2010 3:22 AM, Pieter Hintjens wrote:
>> s1.bind("tcp://127.0.0.1:12345")
>> s2.bind("tcp://127.0.0.1.12345")<<- Gives address already in use.
>>
>> Src ==N==>  W1 ==>N+==>  W2 ==>  Dst
> After reading your explanation it's still unclear to me why you are
> trying to bind to the same endpoint twice, and whether you expect that
> to succeed or not (it won't).
As it happens, my usage case here is transitioning 10 years of Visual 
Source Safe history to Subversion using SourceGear's "SourceOffSite" 
command line tool.

The first stage is to extract the directory structure. The second stage 
is to extract the file lists within the directory structure. The third 
stage is to extract the revision history. Finally, I aggregate the 
revision history by datetime/user to create repository commits suitable 
for subversion.

There is a fairly costly overhead to every invocation of the command 
line tool, which can be excellently amortized by running it in parallel.

I need N workers at stage 2 to be able to forward the list of files they 
find to M workers at stage 3. That is, each worker at stage 2 play the 
downstream role to each of the workers at stage 3.

Stage 2 and stage 3 are running on different machines for performance 
reasons (stage 2 can run anywhere, whereas stage 3 benefits from being 
on the same machine as the SourceOffSite server).

In serial - this task ran for over 54 hours before crashing due to the 
inevitable bit of Visual Source Safe corruption :) First tests seem to 
indicate the parallel run will run upto 10x faster.

def stage1:
 for dir in getDirectories():
 stage2->send(dir)

 while commit = stage4->recv():
 ...

def stage2:
 while dir = stage2->recv():
 for file in getFiles(dir):
 stage3->send(file)

def stage3:
 while file = stage3->recv():
 for commit in getCommits(file):
 stage4->send(commit)

I guess the only way to achieve this is with a concentrator.

def stage2:
 stage3a = connect(zmq.UPSTREAM, concport)
 while file = stage2->recv():
 for file in getFiles(dir):
 stage3->send(file)

def stage3a:
 stage3a = bind(zmq.DOWNSTREAM, concport)
 stage3b = bind(zmq.UPSTREAM, stage3port)
 while file = stage3a->recv():
 stage3b->send(file)

def stage3b:
 stage3b = connect(zmq.UPSTREAM, stage3port)
 while file = stage3b->recv():
 for commit in getCommits(file):
 stage4->send(commit)


As a networking guy, I can understand why that is the way it is. It 
makes less sense as a parallelism guy :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Can't bind same ZMQ_UP/DOWNSTREAM multiple times.

[Oliver Smith]

  import zmq
ctx = zmq.Context(1)
s1 = ctx.socket(zmq.DOWNSTREAM)
s2 = ctx.socket(zmq.DOWNSTREAM)
s1.bind("tcp://127.0.0.1:12345")
s2.bind("tcp://127.0.0.1.12345") <<- Gives address already in use.

This is a simplification of the issue, I am actually experiencing it in 
separate processes/threads on the same system.

Trying to do a multi-stage pipeline where one work-generator sends 
requests on which N threads are listening. These process the requests 
and generate additional requests which they dispatch to a second 
socket_t, beyond which are N more workers which produce the final output 
to a socket_t that feeds back to the original process.

Src ==N==> W1 ==>N+==> W2 ==> Dst

N requests sent to X number of Worker1, which generates 1+ requests to X 
number of Worker2, which generates 1+ results per request to send back 
to the dest port in the originating thread.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ User Guide

[Oliver Smith]

  On 8/13/2010 3:06 AM, Martin Sustrik wrote:
> I would like to point out that with examples in many languages it will
> be impossible to keep them in sync (it's even impossible to keep
> bindings as such in sync) which would result in low quality of the book.
>
> I would let the book focus on C (and say Python for simplicity) and let
> the individual binding developers to provide example code as a part of
> the binding project.
Multiple-languages aside, perhaps take a leaf out of the Mercurial 
Book's example and tie a unit test system to the build process of the 
guide/book?

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ User Guide

[Oliver Smith]

On 8/12/2010 4:29 PM, Pieter Hintjens wrote:


   But I like the idea of
showing the examples in as many languages as possible.

While it pains me to give kudos to Microsoft, I find that MSDN's "Language Selector" is one of 
the main reasons I often pull up MSDN ahead of typing "man".


Mostly I want to use C for real examples, because it's the reference.
I'll translate the Python into C for the first examples, then.

How about the following, then:

* For every example (not the smaller fragments) I'll create a page
* The text will link to that page
* That page will hold space for translation of the example into each language
* People can then translate the examples as they please

This would become a really useful resource.

Does this approach sound practical?

I honestly think it would be worth doing with CSS - as suggested - to hide/show 
various sections.

You'd do something like







...





...





I'm guessing you are using Apache ... I'm an old-school Roxen user. For me it 
would be as simple as:















Or...

Takes one argument: 
name=''

 

  

   



   

   



  

  

 







...



I'm not sure what the equivalent would be for Apache/JSP Tags.

You'd just need something to display a list of languages with something that 
sets the 'hidden' property for code-example-cpp, for example, to 'true' or 
'false'. And voila, you have a document customized to the user's preferences.



[OT/FYI]
Roxen (http://www.roxen.cdom/) is a free/opensource WebServer 
(http://download.roxen.com/, originally called 'Spinner') which pre-dates Apache and had 
features like a web-based configuration interface and XML-based scripting language 
("RXML") since day 1 (circa 1995).

They also provide a commercial CMS that competes with Vignette (I saved Granada 
Media ~EUR300,000 by introducing them to Roxen).

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ User Guide

[Oliver Smith]

  On 8/12/2010 11:06 PM, Chuck Remes wrote:
> Does this mean you finally discovered Bourbon? ;)
Bourbon = weak sauce. Have you ever had Zeer Oude Genever? Stuff smells 
like commercial grade whiteboard cleaner.

And "Kirshwasser"... If you buy a bottle, store it vertically. I made 
the mistake of putting my first bottle horizontally on a rack in the 
fridge. After only 5 hours it had eaten thru the lid, the fridge's 
gasket, and the linoleum on the floor. I was in the middle of cooking 
when the downstairs neighbor came to tell me the ceiling was dripping.

(I don't recall what brand it was, on account of having drunk some of 
the stuff)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ User Guide

[Oliver Smith]

  On 8/12/2010 7:17 PM, Pieter Hintjens wrote:
> OK... I've made these changes.  Now at the foot of every code example
> it links to a page on code:whatever-name which has space for
> translation into each binding language.
Superb! CSS thing not going to happen tonight (incase you were waiting 
on it). [Sigh, I finally found an American alcoholic beverage with 
alcohol in it. I thought a year drinking Zeer-oude-Jenever, Kirschwasser 
and Malteserkreuz had prepared me for anything].

- Oliver


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ User Guide

[Oliver Smith]

On 8/12/2010 2:54 AM, Pieter Hintjens wrote:
>> Suggestion:
>>
>> Text like this needs decoration, like the indent with a graphic that
>> O'Reilly books do...
>>  
> Would you like to propose some CSS and/or graphics to do that?  I'll
> add it to the stylesheet for the page and we can decorate text here
> and there.
>
CSS? {PTSD kicks in} Please sir, let me code that distributed 
transaction encryption system for you in Z80 assembler for you?

(I'll try to send you an example later today)
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ User Guide

[Oliver Smith]

On 8/12/2010 2:47 AM, Mark V wrote:
> Good point.  Maybe the code examples from the main text can
> (eventually) be reproduced in an Examples sub-section for each
> language.
> This suggests systematic labeling each of code examples in the main
> text body.  Maybe beneath each code box
>
>  example: Some description
>
> This way people can easily find the example in their language of
> interest.  E.g. by searching for 'Ruby example 4', or maybe just
> bookmarks can be added as examples are contributed.
>
Factor in that people will wind up in the user's guide in their path to 
discovering 0MQ, and Python (Lua, Perl) can be a huge turn off for some 
people. More often than not, the ease of use of a library/utility from 
scripting environments translates to a PITA for folks working in 
C/C++/C#/Java etc. My total Python time prior to ZeroMQ is less than the 
time I've spent writing this email so far.

It's not a priority, by any means, but if you could factor into the 
design a concept of having multiple language implementations of most 
examples, and using some HTML cleverness to show only those the reader 
is interested in...

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ User Guide

[Oliver Smith]

On 8/12/2010 1:38 AM, Martin Sustrik wrote:
>> Once the guide is complete it looks like it could be published as an
>> O'Reilly book.
>>  
> It really begins to look like a book. Kudos to Pieter!
>
+2 =) Nice work Pieter :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Request: Serialization hook.

[Oliver Smith]

On 8/11/2010 10:50 PM, Steven McCoy wrote:
> As it is C++ why would you not just derive a new function overloading 
> Socket class?
>
> Such semantics would also have requests for encryption, compression, 
> authentication, entitlements, auditing, subscription management, etc.
Because it requires insight into what is underneath the zmq::socket_t.

If you really need encryption/compression, you could do those in your 
serialize, with the advantage of only being invoked when the data is 
actually going out of memory space.


- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ User Guide

[Oliver Smith]

On 8/11/2010 9:30 PM, Matt Weinstein wrote:
> When we were working on (one of the first) network transparent OSs,
> and all of the machinery disappeared (no rcp/scp, no remote
> logins, ...), users didn't understand how they would get a file at a
> distant server without doing anything.  The corresponding metaphoric
> question was: "How do you explain a window to a caveman?" [attr. to G.
> Popek]
>
> We've got a similar problem.  We have to find a way to communicate the
> essential Zen (Ø-ness) of this platform - unification of ubiquitous
> transports into an efficient conceptual and operational framework.
>
> This is the platform's greatest contribution.
>
> Of course, I'm not going to get into the Tao of ØMQ -- yet.
>
Maybe have a link to an "aside" that shows some typical parallelization 
code -- a couple of threads exchanging data through a condition variable 
alongside some ZeroMQ code that does it trivially with message passing?

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Request: Serialization hook.

[Oliver Smith]

I'd like to see making transport mixing a little easier.

Consider the following code:

   struct Foo {
 std::string a ;
 std::vector b ;
   } ;

   zmq::socket_t socket(ctx, ZMQ_REQ) ;
   socket.connect("tcp://192.168.0.1:1234") ;
   socket.connect("ipc://workers") ;

   Foo foo("Hello", { 1, 2, 3, 4 }) ;// C++0x

   zmq::message_t msg(&foo, sizeof(foo), NULL) ;
   socket.send(msg, 0) ;

   zmq::message_t reply ;
   socket.recv(&reply, 0) ;

Depending which endpoint the message gets sent on, this may or may not 
crash.

You *could* create a serialization thread, which actually handles the 
remote socket connect, but this introduces a significant learning curve 
and it defeats the "your code is virtually ready to go!" claim.

I would like to suggest

 zmq_setsockopt(socket, ZMQ_SERIALIZER, function) ;(I don't care 
what it's called, ZMQ_SO_SERIALIZER, whatever :)

The transport would then determine whether 'function' needs to be called 
depending on whether a message is being sent via IPC or out of memory space.

Function would take two parameters: a bool providing true/false whether 
the message is being received or sent, and a pointer to a zmq::message_t.

It would return a pointer to a zmq::message_t.

If the routine determines no work is required, it can return the source 
message. If it returns a new zmq::message_t, then the transport can free 
the old zmq::message_t.

Caveat: Because serialization may take some cpu cycles, this would be a 
good case for having more than one context thread.

Which brings me to another thought: Might it be a good idea to introduce 
a warnings system into the ZeroMQ debug-build flavor.

debugWarn(ZMQ_WARNING_33) ;// ZeroMQ Caution #33: Application called 
recv() on a ZMQ_SUB socket without subscribing to any topics. (See 
zmq_setsockopt).

if ( settingSockOptZMQ_SERIALIZE_FUNCTION and context.numThreads <= 1 )
   debugWarn(ZMQ_WARNING_34) ;// ZeroMQ Caution #34: Consider using 
more than one IO thread in applications which may have to serialize data 
to maintain throughput (see zmq_init)

etc.

Perhaps coupled with a sock-opt for disabling a particular warning - 
e.g. if your recv() is waiting for a term ;)

- Oliver
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ User Guide

[Oliver Smith]

Suggestion:

Text like this needs decoration, like the indent with a graphic that 
O'Reilly books do:


   You could literally throw thousands of clients at this server, all
   at once, and it would continue to work happily and quickly. For fun,
   try starting the client and /then/ starting the server, see how it
   all still works, then think for a second what this means.

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ User Guide

[Oliver Smith]

Suggestion:

Before "Show us the code" - you need a short excerpt on "Isn't message 
passing expensive" where you can mention the lock free element of ZeroMQ 
and expand on the "N-to-N".


   Message passing? Sounds messy and expensive.

   Actually, message passing is just a fancy name for the hand-off of
   marshalled data to someone else. In the simplest, thread-to-thread
   case, it's as simple as passing a pointer. The "Zero" in ZeroMQ
   stands for "Zero Copy".

   In fact, if you've done any work with threads you're probably
   already a message passer - you've just been doing it the hard way
   until now.

   True message passing eliminates the need for mutexes, resource
   locks, condition queues and signals. That makes parallel programming
   easier, cleaner and in most cases it more than pays for the minor
   overhead of a true message passing system. ZeroMQ can compete with
   tools like OpenMP and TBB for sheer performance, but it can also
   work alongside them.

   But best of all, the API doesn't change when you need to step up
   from passing messages between threads of a single process to
   multiple processes or even multiple machines. It's as easy as
   changing the addresses of your connections. ZeroMQ quietly handles
   multiple connections on a single socket for you so you don't have to
   worry about the fiddly networking stuff when you come to make the
   transition.


I'm not sure people are going to register the significance of N-to-N in 
the 100 word section, the transparent multiplexing of the ZeroMQ sockets 
is one of the mind blowing things.


Also... Have you considered perhaps considering the term "Mailbox" or 
"handle" or "descriptor" for the sockets? The more distance you can put 
between the mundane concept of a BSD/TCP socket and a ZeroMQ 
zap-pow-kabloom endpoint the better maybe.


- Oliver
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] 0MQ User Guide

[Oliver Smith]

On 8/11/2010 3:55 PM, Pieter Hintjens wrote:
> I've posted a new version of the user guide, at
> http://www.zeromq.org/docs:user-guide.
>
Suggestion: Show code for more than 1 language. Or get a webby type 
person to make a "language preference" thing near the top or as a side 
bar - kinda like MSDN does. Perhaps ask for two language choices, and 
show them side by side.

- Oliver
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] pub/sub topic matching on sender side

[Oliver Smith]

On 8/10/2010 4:07 AM, j...@totient.demon.co.uk wrote:

[OT] Good to see Demon still going strong :) I was kinda sad when they 
finally stopped using my 8-year-old thttpd build for homepages a year or 
two ago tho :( [If you're a really long-time Demon customer, yes: that 
Oliver Smith]

> Does anyone have any pointers/design sketch on what needs to be changed to 
> get the pub/sub topic match performed in the sender, rather than at the 
> receiver end.
>
> Initially I'm interested in the inter-thread case, but this would also be
> desirable for the tcp/ipc case as well.
>
+1 This has kept me from exploring my main use case for pub/sub.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zmq_poll: timeout issue

[Oliver Smith]

On 8/10/2010 10:00 PM, Steven McCoy wrote:
gettimeofday() is better for most users of RHEL as it can execute in 
user space and transparently use rdtscp() and gain high resolution 
similar to Windows' QueryPerformanceCounter().  The Linux & glibc 
developers are slow to update all the timing APIs to use high 
resolution timers and the POSIX clock API has suffered from changes 
between releases.
The caveat to gettimeofday portability is that of backwards portability. 
One of my old clients still runs the accounting/stock 
control/warehouse/rentals/payroll system I wrote for them 20 years ago 
on Xenix!


It's only relatively recently that gettimeofday stopped being a real 
hefty kernel call overhead.


As long as you are aware of the legacy, gettimeofday is a good choice 
for forward looking portability.



- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] OT: You people suck. Was Re: 0MQ to the rescue

[Oliver Smith]

On 8/10/2010 8:17 AM, Peter Alexander wrote:
> Sorry for this ot post, but I just had to say thanks for mentioning ditaa.
>
> I've been looking for a little gem like this for a long time and don't 
> know why I had not found it myself earlier.

Wha... Wh...

Ok - I'm getting tired of this already. Can you people PLEASE stop 
introducing me to the most god awesome odds and ends of software?

This is supposed to be the zeromq mailing list, not show and tell for 
pieces of software I've been looking for since I was running a bulletin 
board on a BBC model B.



Seriously.

Best. List. Ever.

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] For your amusement: 1 year of ZeroMQ checkins

[Oliver Smith]

On 8/8/2010 1:06 PM, Pieter Hintjens wrote:
> http://www.youtube.com/watch?v=FbyRVY6i_JQ
>
> Wow... watch it in HD and you can see the sweat dripping off Martin
> Sustrik's avatars forehead as he flies around...
>
Rofl ... I had to hack around a LOT to get Martin's avatar to behave. 
I've tried Gource out on a dozen different projects, and some non-source 
projects (web logs, communities within our game), and not had a problem 
:) But Martin's avatar just kept wanting to whoosh off screen.

For extra entertainment value, turn on the Closed Captioning -> 
Transcribe Audio.

"hone this is a quick little video of maine. not just experimenting with 
the schools the".
> Do you have a 3D version?  All the good movies come in 3D these days...
>
Nope - but you have the data, and the source is at 
http://code.google.com/p/gource :)

Maybe you could work some ZMQ magic on it to give it the parallel 
performance it'll need to do that stuff in 3d :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] For your amusement: 1 year of ZeroMQ checkins

[Oliver Smith]

http://www.youtube.com/watch?v=FbyRVY6i_JQ


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Futures

[Oliver Smith]

Something that might excite a lot of developers towards ZeroMQ is an 
easy-to-access Futures concept.

For those who don't know, a Future is a promise to return a result prior 
to your need to use it.

In C++ you might write something like:

 Future i(calculationFunction, param1, param2) ;
 ... do other stuff ...
 return x + i ;// Waits for the result of 
calculationFunction to return to instantiate 'i'.

In ZeroMQ I envisage a "future_t" which is a super-set of message_t

 socket_t socket(ZMQ_REQ) ;
 socket.bind(futureWorkerUrl) ;

 int i ;
#ifdef VARIANT1
 future_t future(
 calculationFunction  //!< Function to invoke.
 , ¶ms   //!< parameter data
 , sizeof(params)   //!< size of param data.
 , &i //!< destination
 , sizeof(i)
 ) ;
 socket.send(future, 0) ;
#else
 future_t future(
   socket   //!< So it can track itself.
 , calculationFunction//!< Function to invoke.
 , ¶ms   //!< parameter data.
 , sizeof(params)   //!< size of param data.
 , &i //!< destination.
 , sizeof(i)
 ) ;
 future.send() ;
#endif

 x = someOtherCalculation() ;
 future.recv() ;
 return x + i ;

This would lend itself to templates, so that C++/C#/Java etc could 
declare implicit futures:

template
class Future
{
public:
 Future(zmq::socket_t& socket_
   , zmq::future_func_t function_, const void* params_, 
size_t paramsSize_)
 : future(socket_, function_, params_, paramsSize_, &result, 
sizeof(result))
 {
 }

public:
 operator _ResultType & ()
 {
 future.recv() ;// Force data to be received.
 return result ;
 }

private:
 zmq::future_t future ;
 _ResultType result ;
} ;

int someFunction()
{
 struct ComplexResult { int i ; float j ; char description[64] ; } ;
 struct ComplexArg { size_t count, depth ; double seed ; } ;

 ComplexArg args = { 99, 100, 1.234 } ;
 Future complexFuture(socket, &args, sizeof(args)) ;

 int x = ...
 /* lots of other processing here */

 // De-referencing
 ComplexResult& result = complexFuture ;
 printf("got result: %s\n", result.description) ;
 return x + (int)(result.i * result.j) ;
}

But there's a gotcha, especially if you are using multiple Futures 
concurrently or in the same function:

1. You either have to create a socket-per future, which means additional 
tear up/down time, or;
2. You have to manually enforce the order in which you consume the results.

Based on my weekend experience with trying to implement parallel sort, 
it seems to me that there needs to be a mechanism for tokenizing 
messages so that a/ a random call to recv() can associate the resulting 
data with something meaningful or b/ you can retrieve a specific message 
from the queue.

Then the future_t could be implemented in terms of an object which does 
something like:

struct future_t
{
 zmq::socket_t socket ;
 zmq::token_t token ;
 void* data ;
 size_t dataSize ;

 future_t(zmq::socket_t& socket_, zmq::future_func_t func_, const 
void* params_, size_t paramSize_, void* data_, size_t dataSize_)
 : socket(socket_), data(data_), dataSize(dataSize_)
 {
 socket.getsockopt(ZMQ_GET_NEXT_SEND_TOKEN, &token) ;
 zmq::message_t msg(params_, paramsSize_, 0) ;
 socket.send(msg, 0) ;
  }

 bool recv()
 {
 socket.setsockopt(ZMQ_SET_NEXT_RECV_TOKEN, &token) ;
 zmq::message_t msg(data, dataSize, 0) ;
 return socket.recv(&msg, 0) ;
 }
}

Any thoughts?

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Connect to a different host, same socket.

[Oliver Smith]

Using C++, I wanted to do the following:

{
 static zmq::socket_t socket(zmqContext, ZMQ_UPSTREAM) ;
 static const char* connectedTo = NULL ;

 if ( connectedTo != NULL )
 {
 socket.close() ;// Disconnect previous connection
 }
 if ( connectedTo != newDestination )
 {
 if ( socket.connect(newDestination) != 0 )
 throw std::invalid_argument("Couldn't connect to 
destination") ;
 else
 connectedTo = newDestination ;
 }

 socket.send(data) ;
}

But the only way to close a socket in C++ seems to be to destroy the 
socket_t?

- Oliver
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Parallel sort

[Oliver Smith]

On 8/2/2010 8:07 PM, Pieter Hintjens wrote:
>> However: if you introduce the overhead of having to create threads on
>> demand, rather than being able to use a pool of pre-existing workers,
>> you'd probably create a situation where - for purely local
>> implementations - OpenMP's "#pragma omp task" or TBB's "TBB::Pipeline"
>> system would be better (tbb in-particular if you are using Intel hardware :)
>>  
> This is why I wonder about the size of your sort set.  A few thousand
> threads would be fine.  Millions would be weird IMO.  There are
> certainly ways to map a very large virtual tree onto a smaller number
> of real worker threads. It just requires some passing of state up and
> down.  Grab state, decide whether to split or execute, return results,
> repeat.  Would work with stateless workers and all state concentrated
> in one dispatcher.
>
Ah - I don't actually have a work load to sort right now, rather I'm 
still working on the whole ZeroMQ vs OpenMP/TBB thing. Parallel sort is 
typically the first thing these libraries demonstrate, leading on to how 
to handle recursive parallelism etc.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Parallel sort

[Oliver Smith]

On 8/2/2010 7:32 PM, Pieter Hintjens wrote:
> Uhm, that'd be 1+n sockets per thread where n might be 2.
>

With mechanisms like these, you need to be careful where you choose 
between scalability (off-device distribution) and performance.

See this post about one of Facebook's developers experimenting with 
Parallel sort in Erlang. 
http://yarivsblog.com/articles/2009/03/09/parallel-merge-sort-in-erlang/

Using lock-based parallelism, I expect a quite drastic performance 
improvement by using a parallel sort over a serial sort. GCC 4.4+ comes 
with STL's parallel/algorithm which includes a parallel_sort.

I think his primary problem was the ratio of compute time to management 
time and setting too low a grain size for "go ahead and do this locally".

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Parallel sort

[Oliver Smith]

On 8/2/2010 7:25 PM, Pieter Hintjens wrote:
> Do you know if the division is binary or n-ary?  I'm thinking each
> node could be multithreaded and have three sockets per thread, one
> connected to a dispatcher, n connected to potential sub-nodes in a
> virtual tree.  Requests flow down the virtual tree, replies flow back
> up.  Each thread waits for replies, consolidates them, sends the
> result back up.
>
It depends on the sort algorithm. "bitonic merge sort", for instance, 
produces binary.

However: if you introduce the overhead of having to create threads on 
demand, rather than being able to use a pool of pre-existing workers, 
you'd probably create a situation where - for purely local 
implementations - OpenMP's "#pragma omp task" or TBB's "TBB::Pipeline" 
system would be better (tbb in-particular if you are using Intel hardware :)

- Oliver

References:

bitonic merge sort: http://en.wikipedia.org/wiki/Bitonic_sorter
#pragma omp task 
http://wikis.sun.com/display/openmp/Using+the+Tasking+Feature
TBB::Pipeline 
http://software.intel.com/en-us/blogs/2007/10/31/tbb-pipeline-class-application-in-text_filtercpp/
 

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Parallel sort

[Oliver Smith]

On 8/2/2010 5:17 PM, Pieter Hintjens wrote:
> Before discussing solutions, could you explain more about the use case?
>
Also, trunk-branch-leaf trees, or forests if you will, as in struct Node 
{ Node* sibling; Node* child; Node* leaf; }.

- Oliver


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Parallel sort

[Oliver Smith]

On 8/2/2010 5:17 PM, Pieter Hintjens wrote:

Not infinite :) I think the issue is one of collection; step X creates N
units of work that require processing and then resumption...
 

You can plug pipelines into themselves.

I'm wondering where you store the data while it's being sorted.  I'm
also wondering why you need to parallelize this.  Is the comparison
particularly expensive?

Before discussing solutions, could you explain more about the use case?
   

It's in the Subject line :)

I've been thinking about this a lot today (how you might sub-division 
parallel work into sub-tasks and then perform a subsequent 
reunification). Fundamentally, it is the same principle as packet 
fragmentation and reassembly.


In this case, it is a message (containing a unit of work) being divided 
into 2 or more subunits. Each of which can potentially be executed by a 
separate thread before finally sending an "ack" to the joiner process.


Here's my theoretical model:

INITIATOR:
Initiator dispatches the meta-workload to the worker pool with a static 
ID/token that is recognized as meaning "first workload, singular".


WORKERS:
The first worker receives this load, performs any pre-processing and 
then divides it into discrete sub units.


It forwards the sub-units via multi-part messages to a third thread, the 
last part of the multi-part message is mostly a copy of the source 
message that triggered this step (for callback purposes). It can't be an 
exact copy otherwise ... you'd just create a loop :) Perhaps the "token" 
contains a "stage" so that this could also serve as a message-passing FSM.


COLLATOR:
The collection thread rejoins the multi-part message and assigns each 
piece of work a token (akin to a segment id). It uses the last part of 
the message as a "completion" reference for where to send the completed 
results, and to obtain "depth" information on the recursion.


It then forwards the subunits back to the worker pool.

WORKERS:
Repeat the above process until they actually complete a piece of work. 
When this occurs, they send what amounts to an "ACK" for the source 
token to the COLLATOR.


COLLATOR:
On receiving an ACK for a token, it removes that token from the 
in-flight queue. If this results in no ACKs pending for a given piece of 
work, the "completion" message is forwarded to the worker pool (again, 
this contains the token from which the subunits were created).


WORKERS:
A worker receives the completion message for a group of subunits and 
performs the necessary post-processing. It then ACKs the token in the 
completion message (i.e. the work unit a level above).


COLLATOR:
When an ACK is received for the parent work, it is forwarded to the 
originating thread, which is presumably sitting in a recv().


This /could/ have some embellishments. Such as the 'stage' component of 
the token descriptor.


Also, the COLLATOR could set limits on the number of tokens in flight 
(to increase efficiency and cache hotness, etc). Hence the need to track 
depth; if you set a limit of, say, 4 tokens, then you would become 
"stuck" at the 3rd level of recursion due to exhausting the number of 
tokens available.


Again this is akin to a networking concept: bandwidth. You would 
presumably want to limit the number of tokens in-flight at any given 
depth to, say, twice the number of worker threads available (to ensure 
that there is always work ready when a thread calls recv()).


I think this should probably be controlled at the COLLATOR level, 
though. C.f.


Worker #1 determines that it has 64 sub-units to dispatch. If it blocks 
at a send() then one of your workers is out of action.


Alternatively, if worker #1 can fire off all 64 sub-units into the 
COLLATORs input, it will free itself to return to the worker pool.


I guess the COLLATOR would have to use poll() so that it can receive 
ACKs independently of work issues. That would interfere with the depth 
handling I mentioned unless it either used distinct sockets per depth 
level... Which sounds excessive but you are already using the 
code/memory involved so it has a huge head start over any additional 
second-tier queueing system inside the collator itself...




- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Parallel sort

[Oliver Smith]

Martin,

> I have no real answer as for now. However, the idea of sending messages
> in (possibly infinite?) loops sound kind of scary.
>
Not infinite :) I think the issue is one of collection; step X creates N 
units of work that require processing and then resumption:

Recurse(work, token)
   if work.load.size <= minimum
 Process(work)
 DispatchToken(Complete, token)
   else
 leftToken = DispatchTask(Recurse, work.left)
 rightToken = DispatchTask(Recurse, work.right)
 DispatchJoin(Join, leftToken, rightToken, work, token)

Join(leftToken, rightToken, work, token)
   PostProcess(work)
   DispatchToken(Complete, token)

Complete(token)
   if token == parentToken
 ReplyToParent() # Tell the parent thread we're finished
   else
 pair = pairs[token]
 if pair.empty() # I'm the first to complete
   pair.push_back(token)
 else
   DispatchTask(pair.work, pair.token)
   delete pair # we're done

ParallelDivideAndConquer(work)
   Recurse(work, parentToken)
   WaitForReply()


(Or something vaguely like that)

I'm thinking it needs a 3 stage system:

- Parent thread, which generates the initial tasks,
- Join thread, which tracks in-flight tokens and collects completed tokens
- Worker threads, which received tokenized work and send completions 
back to the Join thread

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Parallel sort

[Oliver Smith]

So, I decided to try and figure out how to implement a parallel sort 
with ZeroMQ message passing.

At this point, I have more fundamental issues than choosing a good 
parallel sort algorithm so -- for now, forget that is the final goal.

Issue 1: The worker threads be created before any work is dispatched, so 
they can be re-used.
- Multiple threads attempting to bind() or connect() ZMQ_REP on an 
inproc:// socket fail with address in use or connection refused. (D'oh)

Issue 2: Ability to "join" pairs of work for divide and conquer.
- Yeah... I may just have been looking at the screen too long today, but 
I can't figure an elegant (and scalable) way to "join" two completed 
sub-tasks.

Approach 1 (I'm trying to do this in C++, but explaining in Python)

 def divideAndConquer1(work):
 if len(work) <= minsize:
 return directWork(work)
 splitAt = len(work) / 2
 dispatch(divideAndConquer1, work[:splitAt]) # Dispatch right 
sub-unit
 divideAndConquer1(work[:splitAt])# Process left sub-unit myself

 ... join ...

 postProcess(work)
 return work

Approach 2

 def divideAndConquer2(work):
 if len(work) <= minsize:
 return directWork(work)
 splitAt = len(work) / 2
 dispatch(divideAndConquer2, work[:splitAt])# 
Dispatch both workloads...
 dispatch(divideAndConquer2, work[splitAt:])

 ... join ...

 postProcess(work)
 return work

I also experimented with a third approach, where the top-level 
dispatching routine starts from the bottom up, i.e. dispatching all the 
"minsize" workloads for directWork, waiting for them all to complete, 
and then combining those work-units into pairs and dispatching these 
super-units to the level-above processing routine.

But I couldn't figure out how to have a single sender dispatch to a 
multiplexed in-socket capable of sending back a reply; I could use a 
pair of down/up stream sockets like I do in AsyncWorker, but that would 
mean the function could only be used from the master thread (i.e it 
would be thread-unsafe).

Appreciate any feedback or advice on any of the above methods, or if 
someone has actually implemented a pipelined parallel sort (bitonic or 
otherwise) that they don't mind sharing


- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Shortest. Introduction. Ever.

[Oliver Smith]

Pieter Hintjens said the following on 7/30/2010 4:14 AM:
> Hi folks,
>
> Just thought you might enjoy Zed Shaw's introduction to ZeroMQ from
> the mongrel2 docs:
>
> http://mongrel2.org/doc/tip/docs/manual/book.wiki#x1-590005.2
>
Splendid :)

Reading through it reminded me of something, should it perhaps be 
invalid behavior to recv() on a ZMQ_SUB that you have not yet called 
setsockopt(ZMQ_SUBSCRIBE) on?

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] [evangelism?] Debian Package

[Oliver Smith]

Has iMatix considered making a ZeroMQ debian package? Getting ZeroMQ 
visible through the many users of the Debian package system would be a 
great way to get ZeroMQ more recognition.

http://wiki.debian.org/HowToPackageForDebian

Ubuntu, in particular, would be an excellent target for ZeroMQ, since 
there are so many Ubuntu derivatives, and Ubuntu Server and Ubuntu Cloud 
are extremely popular and superb targets for ZeroMQ applications.


- Oliver
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Devices, and pipeline again

[Oliver Smith]

On 7/29/2010 10:46 AM, Pieter Hintjens wrote:
> As you can see I'm using ZMQ_PUSH and ZMQ_PULL in place of
> ZMQ_DOWNSTREAM and ZMQ_UPSTREAM.  It seems to work.  A node pulls
> data, works on it, and pushes it on.  So nodes are pullers, or
> pushers, or both.  It's short, verbish (like the other socket types)
> and feels clear.
>
+1

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Fwd: Problem with IPC

[Oliver Smith]

I also managed to bury this didn't I? :)

- Oliver

 Original Message 
Subject:[zeromq-dev] Problem with IPC
Date:   Mon, 26 Jul 2010 02:05:44 -0500
From:   Oliver Smith 
Reply-To:   0MQ development list 
To: 0MQ development list 



If an UPSTREAM connects to an IPC socket that has already had data sent,
it will not receive the first message sent after connection:

Given the following upstream:

[lua]
 require 'zmq' ; ctx = zmq.init(1) ; s = ctx:socket(zmq.UPSTREAM) ;
s:connect("ipc:///tmp/zmqdemo")
 s:recv()

[python]
 import zmq ; ctx = zmq.Cotnext() ; s = ctx.socket(zmq.UPSTREAM) ;
s.connect("ipc:///tmp/zmqdemo")
 s.recv()

If you now start a downstream in an interpreter

[lua]
 require 'zmq' ; ctx = zmq.init(1) ; s = ctx:socket(zmq.DOWNSTREAM)
; s:bind("ipc:///tmp/zmqdemo")
 s:send("Hello")
 -- restart the upstream
 s:send("blah")
 -- wait a few moments
 s:send("World")

[python]
 import zmq ; ctx = zmq.Context() ; s = ctx.socket(zmq.DOWNSTREAM) ;
s.bind("ipc:///tmp/zmqdemo")
 s.send("Hello")
 -- restart the upstream
 s.send("blah")
 -- wait a few moments
 s.send("World")


The second upstream won't see the "blah" message but it will see the
"World" message.

Note: the "blah" is only being sent /after/ the first upstream has
closed and the second upstream has connected.

Even adding an explicit s:close() / s.close() does not fix this.

- Oliver


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zmq-socket name aliases

[Oliver Smith]

Serge Aleynikov said the following on 7/28/2010 9:30 AM:
> However, maybe the problem is not just with names but with the fact that
> the 0MQ project tries to be too ambitious in squeezing many concepts
> into a single layer of the stack?  There is a reason OSI is made up of 7
> layers where each has its own role and API.
>
There's a reason that OSI isn't as popular as other models ;)
> The 0MQ sockets have session, presentation and possibly some of the
> application layers intrinsically mixed together.  As a result they are
> not really "sockets" but endpoints (?), mailboxes (?), nodes (?), and
> communication channels combined.  While the API is modeled after BSD
> sockets, the implementation beefs them up with rich features of upper
> layers, and as a result the notion of a socket as communication channel
> is somewhat lost together with the ability to identify communicating
> entities.
>
I think, though, that is one of the great aspects of ZeroMQ. It is a 
message passing library, and incorporating all those things seems 
necessary; especially if you want to use it for parallelism otherwise 
you risk losing performance ground.

But it does create a demand for clear variants of the naming conventions 
for people getting used to it.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Authenticated pubsub (was Access control)

[Oliver Smith]

On 7/27/2010 4:10 PM, Burak Arslan wrote:
> also, what concern are you trying to address? integrity?
> confidentiality? (i'm not sure what a game would need) are you doing any
> sort of logging somewhere? if so, do you log messages as cleartext? if
> not, will they be decipherable 10 years from now? where would you store
> the keys?
>
Background: Our game is a first-person (infantry, planes, tanks, boats, 
trucks, at-guns, aa-guns, etc) and strategy (players can choose to 
participate in planning brigade movements, supply organization, etc), 
massively multiplayer WWII simulation based game modelling Europe at 
half scale (so driving a truck from Calais to Antwerpen would take you 
roughly half the time it would take to drive the distance for real).

We operate one "game world" in the US comprising 6 physical servers 
operating 8 distinct server processes which is rated at 3500 user 
capacity, and we have a partner who operates 4 such clusters in China.

This is not new data, but rather I'd like to replace the 10+ year old 
systems that export it from the authoritative server ("strat") to 
various different host processes, often purely for the purpose of 
forwarding to clients.

So anyone can see this data in their game client and we actually make 
the data available, on a 10 minute delay, via an XML/JS feed 
(http://wiretap.wwiionline.com/). But when you're operating on a 
European-theater scale, and in a WWII setting, that leaves opportunity 
for surprises. What we don't want is for people to easily make bots that 
can tap into the feed and provide them automated analysis.

So the data would likely be sent in a binary format, but not 
particularly encoded.

And we do actually have 9+ years of logs :) Note, 2001 not 2010.

DebugMessage System Open. Wed June  6th 2001 09:39:22
N [Wed 6/6 09:39.22.293 teulTransport.cpp:531] initializing teulClient 
teul compiled Jun 5 2001 at 15:09:00
I [Wed 6/6 09:39.22.293 teulEndpoint.cpp:1147] MAX_LOCAL_CONNECTIONS 
2500 MAX_TOTAL_CONNECTIONS 5000 freeEndpoints 2500

The game uses a proprietary server infrastructure ("teulServer") so that 
every process is aware of who is currently logged into the cluster from 
where. For us, the authentication token could thus be as simple as the 
player's game name, which we could look up from the "who's online table" 
to determine whether or not to let them subscribe.

But we also have a purposed "one time password" authentication token 
generator that we could use.

The design and implementation of our game servers is actually message 
based. Just message based in really old-school C which means there's a 
metric ton of work in encapsulating every message, and the transport 
library component almost qualifies itself as "UDP over TCP". Please, 
don't ask me how, but somehow the guys who wrote the initial system 10 
years ago managed to achieve unreliable messaging over tcp ;)


- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Off topic

[Oliver Smith]

On 7/27/2010 3:12 PM, Nicholas Piël wrote:
> Ok, +1 on the ZMQ_IGOTBYTES for the sending side.
> But it surely has to be ZMQ_ICANHAZBYTEZ for the receiving side.
>
Error codes would need renaming also.

EAGAIN = EET_HAZ_A_FLAVA
EPROTONOSUPPORT = EET_HAZ_NO_FLAVA
EADDRNOTAVAIL = EH_CEILING_CAT_IZ_WATCHIN_U_FAIL


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Off topic

[Oliver Smith]

On 7/27/2010 2:24 PM, Matt Weinstein wrote:
> We needed one of these after today :-)

If you know what a 'rage thread' is ...

http://www.kfs.org/~oliver/images/zzzeromq.jpg 


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zmq-socket name aliases

[Oliver Smith]

On 7/27/2010 1:03 PM, Brian Granger wrote:
> I completely agree that most people will want to use the canonical 
> directions, but I do think it is misleading to hide the fact that the 
> choice of bind/connect is completely independent of the socket type. 
>  When people ask me if a socket should bind or connect, I tell them 
> that the decision to bind/connect is independent of the socket type 
> and that if you want a socket to have multiple peers, it should bind, 
> a single peer, it should connect.
But you can connect() to multiple peers

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zmq-socket name aliases

[Oliver Smith]

On 7/27/2010 12:44 PM, Pieter Hintjens wrote:
>> ...
>>  
> All good points, and this was where we stopped the proposal to rename
> socket types last time around.
>
Fortunately, alias != rename :)

I want to continue typing "ZMQ_REP" and "ZMQ_PUB" when I am hacking away 
in lua/perl/python and
nobody is ever going to see my code :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Authenticated pubsub (was Access control)

[Oliver Smith]

On 7/27/2010 12:28 PM, Pieter Hintjens wrote:
> Here is, I think, how to build an authenticated pubsub service using
> 0MQ.  The design handles authentication, arbitrary routing criteria,
> and flushing of dead client connections.
>
Thanks, Pieter: Giving it some thought now :)

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Fwd: Access control

[Oliver Smith]

On 7/27/2010 12:18 PM, Martin Sustrik wrote:
> As for real solution the only way to have authenticated pub/sub IMO is
> to encrypt messages on publisher and decrypt them on terminal
> subscriber. (All the intermediate untrusted nodes would just forward
> encrypted data.)
>
> Only subscribers with correct key would be able to make any use of the
> messages then.
>
You'd still have to implement a per-subscriber authentication system to 
achieve this, only now it would be an independent mechanism, sending 
data on a second system.



- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Fwd: Access control

[Oliver Smith]

On 7/27/2010 12:13 PM, Martin Sustrik wrote:
> Well, I am not a security person, but I thought blocking particular IP
> addresses is more of an administrative task and should be done using
> firewall, no?
>
If you are running under a Linux environment using ZeroMQ, there is no 
excuse for you not to send a message to a worker to create an ipchains 
or ipfw rule to block that address :) Of course, in doing so, you may 
wipe out an entire ISP that uses a NAT, but still.

And if you are running under Windows Server, they provide a quite 
sufficient API for firewalling.

A 2010-app(*) still needs to be security conscious, but it should not be 
re-implementing the firewall it lives behind :)

- Oliver

(* it doesn't live behind a firewall? That's so 1999)

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zmq-socket name aliases

[Oliver Smith]

On 7/27/2010 11:01 AM, Pieter Hintjens wrote:
>> Primarily: using stdin/stdout may cause naming conflicts and confusion
>>  
> Probably.  The pipeline pattern is the only one without clear roles
> for nodes (see http://api.zeromq.org/zmq_socket.html)
>> they are only borrowing from the concept of stdin/stdout, they are in no way
>> related. Plus we don't want someone to misunderstand them as the default
>> sockets for zmq.
>>  
> Borrowing is good, especially when it works as you'd expect.
>
Yep - but in this case I think there is too much baggage with borrowing 
the 'std' prefix there :) Just the suffix (in/out) should be sufficient, 
because it follows the paradigm ... stdin, stdout, STDIN, STDOUT, 
std::cin, std::cout, etc, etc.

> I'd be careful about inventing new concepts (generator, broker) that
Valid point, consider broker/generator withdrawn :)
>> ZMQ_SOCK_BROADCAST_PUBLISHER (aka ZMQ_PUB) =>  zmq.sock.broadcast.publisher
>> ZMQ_SOCK_BROADCAST_SUBSCRIBER (aka ZMQ_SUB) =>  zmq.sock.broadcast.subscriber
>>  
> BROADCAST is nice but the pattern is called "pubsub" and one reason
> for the long names is to make pattern names explicit so people are
> less likely to mix the wrong socket types.  If we were going to rename
> it, I'd suggest TOPIC, which is an existing unsurprising term.
>
I think PUBSUB works well enough.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Fwd: Access control

[Oliver Smith]

On 7/27/2010 10:54 AM, Pieter Hintjens wrote:
>> Wait - they can connect to our publisher: otherwise the Internet
>> wouldn't be much use from behind NAT. It's just making connections back
>> to them that's difficult.
>>  
> Of course they can connect to the publisher but there is no way for
> your application code to authenticate those connections.
>

So, what I'm thinking is a zmq::authpub_t, which has as it's members 
both a zmq::rep_t and a zmq::pub_t, matched with a zmq::authsub_t, which 
has zmq::req_t and zmq::sub_t.

Messages received by the authpub_t would be assumed to be auth messages, 
and forwarded to the authpub_t owner to approve. Response routing is 
enabled for the socket at this point, so when the authpub_t owner next 
calls send() it is assumed to be a response to the last message.

During the authpub_t::send we'd do something like ('m_' prefix just to 
emphasize member variables in the absence of a full definition)

 if ( expectingAReply )
 {
 m_authConditionMet = 
this->hasSocketOption(ZMQ_AUTHPUB_AUTHORIZED) ;
 m_reqSocket.reply(msg) ;
 if ( m_authConditionMet )
 {
 // Clear the flag for future reference.
 this->setsockopt(ZMQ_AUTHPUB_AUTHORIZED, 0) ;
 this->xattach_pipes(...) ; // Transfer the connection from 
the reqSocket to the outgoing pipe list.
 // so the underlying connection is no-longer associated 
with the m_reqSocket.
 }
 m_expectingAReply = false ;
 }
 else
 {
 internalPubSocket.send(msg) ;
 }


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Fwd: Access control

[Oliver Smith]

On 7/27/2010 10:54 AM, Pieter Hintjens wrote:
>> Wait - they can connect to our publisher: otherwise the Internet
>> wouldn't be much use from behind NAT. It's just making connections back
>> to them that's difficult.
>>  
> Of course they can connect to the publisher but there is no way for
> your application code to authenticate those connections.
>
Ah - that's where initially treating the socket as a REQ/REP came in: 
they would connect to me, send me their authentication data, and if 
that's accepted, then I would move that underlying socket to the members 
of my middle-level pub/sub pair (with me as pub, them as sub).

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zmq-socket name aliases (was: Re: Why ZeroMQ?)

[Oliver Smith]

Pieter's list:

http://www.zeromq.org/draft:socket-type-names

   * ZMQ_SOCK_REQREP_CLIENT (aka ZMQ_REQ).
   * ZMQ_SOCK_REQREP_SERVICE (aka ZMQ_REP).
   * ZMQ_SOCK_REQREP_CLIENT_ASYNC (aka ZMQ_XREQ).
   * ZMQ_SOCK_REQREP_SERVICE_ASYNC (aka ZMQ_XREP).
   * ZMQ_SOCK_PUBSUB_PUBLISHER (aka ZMQ_PUB).
   * ZMQ_SOCK_PUBSUB_SUBSCRIBER (aka ZMQ_SUB).
   * ZMQ_SOCK_PIPELINE_STDIN (aka ZMQ_PIN).
   * ZMQ_SOCK_PIPELINE_STDOUT (aka ZMQ_POUT).
   * ZMQ_SOCK_EXCLUSIVE_PEER (aka ZMQ_PAIR).

My $0.01 (I'm too cheap to go the whole $0.02 just yet ;)

Primarily: using stdin/stdout may cause naming conflicts and confusion 
-- they are only borrowing from the concept of stdin/stdout, they are in 
no way related. Plus we don't want someone to misunderstand them as the 
default sockets for zmq.


ZMQ_SOCK_REQREP_GENERATOR (aka ZMQ_REQ, the requester)  => 
zmq.sock.reqrep.generator
ZMQ_SOCK_REQREP_BROKER (alias for ZMQ_REP, the responder) => 
zmq.sock.reqrep.broker

ZMQ_SOCK_REQREP_GENERATOR_ASYNC (aka ZMQ_XREQ) => problem
ZMQ_SOCK_REQREP_BROKER_ASYNC (aka ZMQ_XREP)=> problem
ZMQ_SOCK_BROADCAST_PUBLISHER (aka ZMQ_PUB) => zmq.sock.broadcast.publisher
ZMQ_SOCK_BROADCAST_SUBSCRIBER (aka ZMQ_SUB) => zmq.sock.broadcast.subscriber
ZMQ_SOCK_PIPELINE_OUT (aka ZMQ_POUT) => zmq.sock.pipeline.out
ZMQ_SOCK_PIPELINE_IN (aka ZMQ_PIN) => zmq.sock.pipeline.in
ZMQ_SOCK_EXCLUSIVE_PEER (aka ZMQ_PAIR) => zmq.sock.exclusive.peer


- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Fwd: Access control

[Oliver Smith]

On 7/27/2010 9:56 AM, Pieter Hintjens wrote:
>> Unfortunately many of our subscribers would be behind multiple layers of
>> firewall and NAT.
>>  
> Right, that means you can't use pubsub for this.
>

Wait - they can connect to our publisher: otherwise the Internet 
wouldn't be much use from behind NAT. It's just making connections back 
to them that's difficult.

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] [otish] "Why ZeroMQ"

[Oliver Smith]

On 7/27/2010 9:20 AM, Ben Kloosterman wrote:
> I find "socket" quite confusing , all my work is inproc  or via IPC an no
> where am I using TCP sockets..
>
>
> I still think PROD ( Producer) and CON ( Consumer) are very clear PartA
> produces and PartyB consumes , in and out are always relative to who you are
> talking about A out is Bs in
>
True, but that doesn't break the naming convention for exactly that 
reason :)

Still - producer and consumer are well suited to the parallelism domain.

+1

- Oliver

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Fwd: Access control

[Oliver Smith]

On 7/27/2010 9:07 AM, Pieter Hintjens wrote:
> Now to your problem of authenticating subscribers.  I imagine you're
> not actually using multicast but TCP unicast, right?  A ZMQ_PUB socket
> can connect to a ZMQ_SUB socket.  So imagine that subscribers connect
> to the publisher via REQ-REP and provide their endpoint along with
> authentication credentials.  The publisher verifies that and if it
> matches, connects through to their endpoint.  The publisher does not
> bind(), so has no endpoint for unauthorized subscribers to connect to.
>
The subscribers bind their sockets, and the publisher performs the 
connect()?

Unfortunately many of our subscribers would be behind multiple layers of 
firewall and NAT. So ideally I'd want the ability to move the endpoint 
(real-socket) from the zmq-req-rep socket to my zmq-pub socket.

Hmm. I'll have to sit and look at the actual implementation of req/rep, 
but perhaps it would be possible to implement a "rep-pub" class, which 
you receive a request on, to which you reply once.

Underneath, it is actually two zmq-sockets. One is a req/rep socket, 
which handles routing of auth requests/replies. The other is a ZMQ_PUB 
socket.

When it sees what it recognizes as an auth-accept, it send the reply and 
transfers the underlying endpoint to the zmq_pub socket.

Example usage:

ctx = zmq.context()
pubSock = ctx.socket(ZMQ_AUTHED_PUB)
pubSock.bind("tcp://1.2.3.4:1234")
do
   p = pollitems( { pubSock, zmq.POLLIN} )
   if ctx.poll(p, nil, 100) == 0 then
 # Reached time out, send data
 msg = generateMessage()
 pubSock.send(msg)
   else
 # Received a msg on pubSock
 msg = pubSock.recv()

 if approved(msg) then
   # the send routine will clear the sock opt
   # after checking for it.
   pubSock.setsockopt(zmq.PUB_AUTHORIZED)
   pubSock.send(makeApprovalMsg(msg))

   # at this point, the underlying endpoint has now been
   # moved to the AUTHED_PUBs PUB socket.
 else
   pubSock.send("begone, intruder!")
 end
   end
end


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev