[zeromq-dev] Any API to fetch 0mq socket structure from fd?

2013-05-20 Thread Manish Mehra
I have an application in which the server is listening on a socket. When
clients connect, I need to know the per client “fd” and the client address.
This info can be fetched using the socket monitors APIs. Subsequently, I
need to send data separately for each client. (not send same data to all
clients). The send API needs *void pointer*. Is there a standard API to get
socket structure (void pointer) from “fd” which I can use in send API?
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


[zeromq-dev] debian zeromq links update

2013-05-20 Thread Stephen Hemminger
Several links about Debian packages on
 http://www.zeromq.org/distro:debian
are out of date.

1. There is libzmq for squeeze-backports
 http://packages.debian.org/squeeze-backports/libzmq1

2. You should add jessie release now as well
  http://packages.debian.org/source/jessie/zeromq

3. The link to experimental for 3.2 is dead. I think the correct link is:
  http://packages.debian.org/sid/libzmq3

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


Re: [zeromq-dev] (no subject)

2013-05-20 Thread Mikko Koppanen
Hello,

the instructions for building on Windows are available here:
https://wiki.php.net/internals/windows/stepbystepbuild. They apply to
pretty much all PECL extensions that have config.m4. Tiny bit older
binaries are available here: http://valokuva.org/~mikko/php-zmq-20130203.tgz

Thanks,
Mikko


On Tue, May 21, 2013 at 6:32 AM, Uli Köhler
wrote:

> Hi,
> I agree, this should be fixed somehow.
> Maybe the PEAR page here:
> http://pear.zero.mq/
> or the PHP 0MQ repository https://github.com/mkoppanen/php-zmq
> can help you, the
>
> Mikko Koppanen also has a 0MQ snapshots repository:
> https://github.com/mkoppanen/zeromq-snapshots
>
> The last activity is 2 years ago, but there might be a build script for
> 0MQ-PHP somewhere.
>
> Best regards
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>


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


Re: [zeromq-dev] inproc sockets

2013-05-20 Thread Pieter Hintjens
On Tue, May 21, 2013 at 12:25 AM, Andrew Hume  wrote:

> for example, if each of two threads needs to do a bind, and a connect to the
> other's bind, then this becomes a complicated dance.

Uhm, I'd say you have other problems if you create two co-dependent
threads like this. The only use case I can think of is when I want to
demonstrate how to write such a bogus (excuse me :-) piece of code
using 0MQ that it will deadlock. Decent upright tasks should never be
co-dependent like this.

> i guess its not bad if all the binds are independent, and all the connects
> depend only on the binds.
> but if any of this depends on other connections, then its really bad.
> (but maybe it always is.)

Inproc architectures cannot be random; they follow a structure and
that should IME be *strictly* hierarchical, so bind can always come
before connect. This saves inproc, by some luck, because it wasn't
clear when the transport was designed.

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


Re: [zeromq-dev] (no subject)

2013-05-20 Thread Uli Köhler
Hi,
I agree, this should be fixed somehow.
Maybe the PEAR page here:
http://pear.zero.mq/
or the PHP 0MQ repository https://github.com/mkoppanen/php-zmq
can help you, the

Mikko Koppanen also has a 0MQ snapshots repository:
https://github.com/mkoppanen/zeromq-snapshots

The last activity is 2 years ago, but there might be a build script for
0MQ-PHP somewhere.

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


Re: [zeromq-dev] inproc sockets

2013-05-20 Thread Andrew Hume
thanks.

i observe that this works in simple cases, like i luckily have, but does not 
generalise.
for example, if each of two threads needs to do a bind, and a connect to the 
other's bind,
then this becomes a complicated dance.

i guess its not bad if all the binds are independent, and all the connects 
depend only on the binds.
but if any of this depends on other connections, then its really bad.
(but maybe it always is.)

On May 20, 2013, at 3:16 PM, Pieter Hintjens wrote:

> On Mon, May 20, 2013 at 5:29 PM, Andrew Hume  wrote:
> 
>> what is the preferred mechanism for having threads talk to one another?
> 
> CZMQ's zthread_fork method does this in a way that seems robust and simple.
> 
> Parent thread creates two sockets, binds one, connects the other,
> creates a thread, and passes it one end of the pipe. The child thread
> can then talk to the parent over the pipe. We use PAIR sockets for
> that.
> 
>> the old way was for the main program to do the bind
>> before spawning threads who do the connect,
>> and passing that bind socket to teh thread who needs it.
> 
> Yes, this is the other pattern we use (in the Guide examples): parent
> creates socket and binds it, then starts child threads, which connect.
> 
>> the new meme talks about creating sockets within threads
>> but it is awkward to arrange the bind first.
> 
> The only complex part is when you want different sub-threads to
> connect safely; in that case I use the pipe mechanism to signal
> "ready" from threads, back to the main, before starting further
> threads.
> 
> -Pieter
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


---
Andrew Hume
623-551-2845 (VO and best)
973-236-2014 (NJ)
and...@research.att.com



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


Re: [zeromq-dev] (no subject)

2013-05-20 Thread Joyce Norris
The snapshot server has been down since August and the documentation still 
references it.  Shouldn't one of

those two things be fixed?



Do you have information on how to build for Windows?  I poked around in the 
source and could not find

any references to the php string let alone a project to build.  The only build 
instructions are for Linux.



Joyce






From: zeromq-dev-boun...@lists.zeromq.org [zeromq-dev-boun...@lists.zeromq.org] 
on behalf of Uli Köhler [ulikoehler@googlemail.com]
Sent: Monday, May 20, 2013 5:08 PM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] (no subject)

Hi​,
The snapshot server seems to be down, see this mailing list thread:
http://lists.zeromq.org/pipermail/zeromq-dev/2012-August/018414.html

I've never used 0MQ with PHP, but I suppose your best option is to try to 
compile it yourself!

Best regards

This message is for the addressee's use only. It may contain confidential 
information. If you receive this message in error, please delete it and notify 
the sender. Tripp Lite disclaims all warranties and liabilities, and assumes no 
responsibility for viruses which may infect an email sent to you from Tripp 
Lite and which damage your electronic systems or information. It is your 
responsibility to maintain virus detection systems to prevent damage to your 
electronic systems and information.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] inproc sockets

2013-05-20 Thread Pieter Hintjens
On Mon, May 20, 2013 at 5:29 PM, Andrew Hume  wrote:

> what is the preferred mechanism for having threads talk to one another?

CZMQ's zthread_fork method does this in a way that seems robust and simple.

Parent thread creates two sockets, binds one, connects the other,
creates a thread, and passes it one end of the pipe. The child thread
can then talk to the parent over the pipe. We use PAIR sockets for
that.

> the old way was for the main program to do the bind
> before spawning threads who do the connect,
> and passing that bind socket to teh thread who needs it.

Yes, this is the other pattern we use (in the Guide examples): parent
creates socket and binds it, then starts child threads, which connect.

> the new meme talks about creating sockets within threads
> but it is awkward to arrange the bind first.

The only complex part is when you want different sub-threads to
connect safely; in that case I use the pipe mechanism to signal
"ready" from threads, back to the main, before starting further
threads.

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


Re: [zeromq-dev] (no subject)

2013-05-20 Thread Uli Köhler
Hi​,
The snapshot server seems to be down, see this mailing list thread:
http://lists.zeromq.org/pipermail/zeromq-dev/2012-August/018414.html

I've never used 0MQ with PHP, but I suppose your best option is to try to
compile it yourself!

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


[zeromq-dev] (no subject)

2013-05-20 Thread Joyce Norris
Hi,



I am trying to use ZMQ with PHP.



The instructions at http://www.zeromq.org/bindings:php state



Download the latest snapshot from http://snapshot.zero.mq/

Copy libzmq.dll into your php directory (e.g. C:\wamp\bin\php\php5.3.8\)

Copy the appropriate version of php_zmq.dll to your php extension directory 
(e.g. C:\wamp\bin\php\php5.3.8\ext)

Add the following line to your php.ini:

extension=php_zmq.dll


Restart your web server to pickup the ini changes



I tried to get the .dll from the snapshot but cannot connect to 
http://snapsho.zero.mq



Where can I get a copy of php_zmq.dll?



Joyce






This message is for the addressee's use only. It may contain confidential 
information. If you receive this message in error, please delete it and notify 
the sender. Tripp Lite disclaims all warranties and liabilities, and assumes no 
responsibility for viruses which may infect an email sent to you from Tripp 
Lite and which damage your electronic systems or information. It is your 
responsibility to maintain virus detection systems to prevent damage to your 
electronic systems and information.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] how to use "inproc" for connecting C# and C++ (how to share context?)

2013-05-20 Thread Oleg Vazhnev
Thanks Pieter!

So far I replaced zmq with single delegate call, it takes about 8 
microseconds to deliver pointer from c++ to c# on my machine.

BTW sharing between c and c++ sounds easy because i can use c classes 
from c++. In c# i can not use c-style zeromq "context" class... So I 
guess I need some "portable" way to represent context. Probably "int 
contextId" or something like that... i will look at examples you suggest 
probably answer is there :)


15.05.2013 1:22, Pieter Hintjens пишет:
> Look at how CZMQ creates threads (the zthread module). Then your
> parent (e.g. C++) starts C threads and passes its context. The two can
> then communicate over inproc.
>


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


Re: [zeromq-dev] PUB/SUB appears to be 'missing' first byte 3.2.2

2013-05-20 Thread Trevor Bernard
What version of JZMQ are you using?

I ran your test program and received the correct results.

JZMQ - 018a38d414af4e689c93e29d4d7a59a1f51fe84e
libzmq 3.2.2

On Mon, May 20, 2013 at 1:45 AM, Mark Sutheran  wrote:
> Hi Pieter,
>
> Thanks for the quick response - test case below.
>
> Tested it using ipc and tcp transports - no difference. The trigger appears
> to be the flag used in the send() method. Setting this to 1 (ZMQ.NOBLOCK)
> causes the unexpected behaviour on the second box.
>
> Logs:
>
> Machine 1 (Ubuntu 12.04 64, JZMQ/ZMQ 3.2.0)
>
> Blocking pub: [7, 0, 0, 13, -49, 0, 0]
> ...received data: [7, 0, 0, 13, -49, 0, 0]
> Non-blocking pub: [7, 0, 0, 13, -49, 0, 0]
> ...received data: [7, 0, 0, 13, -49, 0, 0]
>
> Machine 2 (Ubuntu 12.04 64, JZMQ/ZMQ 3.2.2)
>
> Blocking pub: [7, 0, 0, 13, -49, 0, 0]
> ...received data: [7, 0, 0, 13, -49, 0, 0]
> Non-blocking pub: [7, 0, 0, 13, -49, 0, 0]
> ...received data: [0, 0, 13, -49, 0, 0]
>
> Regards,
> Mark
>
> Jzmq test case:
>
> /*/
>
> package zmqtest;
>
> import java.util.Arrays;
>
> import org.zeromq.ZMQ;
>
> public class ZMQTest {
>
> private static final ZMQ.Context context = ZMQ.context(1);
> private static final ZMQ.Socket subscriber = context.socket(ZMQ.SUB);
> private static final String tcpPort = "";
>
> private static final byte[] TEST_DATA = new byte[]{7, 0, 0, 13, -49, 0, 0};
>
> public static void main(String[] args) {
>
> System.out.println("Using ZMQ version: " + ZMQ.getVersionString());
> subscriber.connect("tcp://localhost:" + tcpPort);
> subscriber.subscribe(new byte[]{});
> Thread t = new Thread(new SubscriptionDataHandler());
> t.setName("SubscriptionDataHandlerThread");
> t.setDaemon(true);
> t.start();
>
> ZMQ.Socket publisher = context.socket(ZMQ.PUB);
> publisher.bind("tcp://*:" + tcpPort);
> try {
>
> for (int i = 0; i < 3; i++) {
> System.out.println("Blocking pub:\t\t" + Arrays.toString(TEST_DATA));
> publisher.send(TEST_DATA,0);
> Thread.sleep(1000l);
> System.out.println("Non-blocking pub:\t" + Arrays.toString(TEST_DATA));
> publisher.send(TEST_DATA,ZMQ.NOBLOCK);
> Thread.sleep(1000l);
> }
> Thread.sleep(500l);
>
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> private static final class SubscriptionDataHandler implements Runnable {
>
> @Override
> public void run() {
> System.out.println("SubscriptionDataHandler thread starting");
> while (true) {
> final byte[] rec = subscriber.recv(0);
> System.out.println("...received data:\t" + Arrays.toString(rec));
> }
> }
> }
> }
>
>
> 
> From: Pieter Hintjens 
> To: Mark Sutheran ; ZeroMQ development list
> 
> Sent: Sunday, 19 May 2013, 17:04
> Subject: Re: [zeromq-dev] PUB/SUB appears to be 'missing' first byte 3.2.2
>
> Hi Mark,
>
> Would you provide a minimal test case that demonstrates the problem?
>
> Thanks
> Pieter
>
> On Sat, May 18, 2013 at 6:56 PM, Mark Sutheran 
> wrote:
>> Hi,
>>
>> I appear to have a issue with PUB/SUB apparently 'dropping' the first
>> byte.
>>
>> Setup:
>>  * Basic PUB/SUB running on same machine over TCP/localhost.
>>  * Message has first 4 bytes as subscription id, rest payload
>>
>> Problem:
>>  * On dev box runs fine
>>  * On prod box the subscriber sees no messages
>>  * The reason is that the received message is 'missing' the first byte
>>
>> Logs:
>>
>> Machine 1 (Ubuntu 12.04 64, JZMQ/ZMQ 3.2.0) runs fine, e.g.:
>>
>> 01:19:10:042 DEBUG [qtp1866572071-24] Publishing: [0, 0, 0, 13, -49, 0, 0,
>> 1, 62, -72, -90, -29, 63, 7, -108, -53, 63, -12, -122, -13, 110, -8, 5,
>> 96,
>> -53, 64, 89, -9, -101, -128, 35, -90, -50, -53, 0, 0, 0, 0, 0, 0, 0, 0,
>> -53,
>> 64, 68, 0, 0, 0, 0, 0, 0, 0]
>> 01:19:10:042 DEBUG [SubscriptionDataHandlerThread] Received data: [0, 0,
>> 0,
>> 13, -49, 0, 0, 1, 62, -72, -90, -29, 63, 7, -108, -53, 63, -12, -122, -13,
>> 110, -8, 5, 96, -53, 64, 89, -9, -101, -128, 35, -90, -50, -53, 0, 0, 0,
>> 0,
>> 0, 0, 0, 0, -53, 64, 68, 0, 0, 0, 0, 0, 0, 0]
>>
>> Machine 2 (Ubuntu 12.04 64, JZMQ/ZMQ 3.2.2) and the subscriptions
>> 'disappear'... digging into it the receiver appears to drop the first byte
>> of the messages 100% of the time, e.g.:
>>
>> 05:20:01:603 DEBUG [qtp1038722314-22] Publishing: [0, 0, 0, 13, -49, 0, 0,
>> 1, 62, -72, -90, 61, 85, 7, -108, -53, 63, -12, -122, -13, 110, -8, 5, 96,
>> -53, 64, 89, -9, -101, -128, 35, -90, -50, -53, 0, 0, 0, 0, 0, 0, 0, 0,
>> -53,
>> 64, 68, 0, 0, 0, 0, 0, 0, 0]
>> 05:20:01:603 DEBUG [SubscriptionDataHandlerThread] Received data: [0, 0,
>> 13,
>> -49, 0, 0, 1, 62, -72, -90, 61, 85, 7, -108, -53, 63, -12, -122, -13, 110,
>> -8, 5, 96, -53, 64, 89, -9, -101, -128, 35, -90, -50, -53, 0, 0, 0, 0, 0,
>> 0,
>> 0, 0, -53, 64, 68, 0, 0, 0, 0, 0, 0, 0]
>>
>> Connecting Machine 1 (SUB) to Machine 2 (PUB) also produces the same
>> results.
>>
>> It's presumably an issue with my code however, it's the same code running
>> on
>> bot

[zeromq-dev] inproc sockets

2013-05-20 Thread Andrew Hume
what is the preferred mechanism for having threads talk to one another?

the old way was for the main program to do the bind
before spawning threads who do the connect,
and passing that bind socket to teh thread who needs it.

does this still work?
the new meme talks about creating sockets within threads
but it is awkward to arrange the bind first.

---
Andrew Hume
623-551-2845 (VO and best)
973-236-2014 (NJ)
and...@research.att.com



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