[zeromq-dev] Windows and PGM

[Jon Dyte]

Martin Sustrik wrote:
> gonzalo diethelm wrote:
>
>   
>> I am doing something similar in my own system. I think it all boils down
>> to defining "connections" (for lack of a better term), which are a
>> combination of:
>>
>> * Name: unique identity
>> * Endpoint: inproc://pipe, tcp://172.0.0.1:5000, etc.
>> * Type: PUB, SUB, REQ, REP, etc.
>> * Action: bind, connect
>>
>> If you could pass a list of these to your class, then you would simply
>> create all these "connections" and then have a poll loop in your own
>> thread. 
>>     
>
> What I am trying to avoid is to pass large number of parameters to the 
> API. In addition to the above, socket options should be passed etc. What 
> if you just passed fully established sockets to the API?
>
> void *zmq_device (int type, void *in_socket, void *out_socket);
> int zmq_device_close (void *device);
>
>   
In the queue class in zmq_queue.cpp, i took the decision to pass in the 
sockets
like this for the same reason.

I mentioned at the time to Martin that ideally the queue concepts, 
forwarder and
and streamer should all be available for use inprocess as well.
Martins's issue was that they need to be done so a C api can work.


>> So for a streamer you could have:
>>
>>   ear = <tcp://127.0.0.1:5001; REP; bind>
>>   mouth = <tcp://127.0.0.1:5002; REQ; connect>
>>
>> Then your class would know it has to create "ear" and "mouth" and then
>> start polling.
>>
>> This could apply to any kind of "device"; a node in my topology might
>> need a SUB socket, a REQ socket and an UPSTREAM socket, which I would
>> define this way as well.
>>     
>
> So what you'll have would look something like this:
>
> void *ear = zmq_socket (ctx, ZMQ_SUB);
> zmq_bind (ear, "tcp://127.0.0.1:5001");
> zmq_setsockopt (ear, ZMQ_SUBSCRIBE, "forex.", 6);
> void *mouth = zmq_socket (ctx, ZMQ_PUB);
> zmq_connect (ear, "tcp://127.0.0.1:5001");
> zmq_device (ZMQ_FORWARDER, ear, mouth);
>
> Thoughts?
>   
I quite like this as a C solution and a more friendly C++ could be done.

I also see gonzalo's point about the loop being run outside ( I implemented
the zmq_poll loop in a method called run on my queue class., but it 
looks like for maximum
flexibility it should be outside.


Jon