Re: [zeromq-dev] ZMQ reconnect/ephemeral ports

[Luca Boccassi]

On Fri, 2017-09-01 at 18:03 -0400, Bill Torpey wrote:
> Thanks Luca!  That was very helpful.
> 
> Although it leads to a couple of other questions:
> 
> - Can I assume that a ZMQ disconnect of a tcp endpoint would only
> occur if the underlying TCP socket is closed by the OS? Or are there
> conditions in which ZMQ will proactively disconnect the TCP socket
> and try to reconnect?

Normally that's the case - you can set up heartbeating with the
appropriate options and that will kill a connection if there's no
answer

> - I see that there is a sockopt (ZMQ_RECONNECT_IVL) that can be set
> to -1 to disable reconnection entirely.  In my case, the the “data”
> socket pair will *always* connect to an ephemeral port, so I *never*
> want to reconnect.  Would this be a reasonable option in my case, do
> you think?

If that makes sense for your application, go for it - in these cases
the only way to be sure is to test it and see how it works

> - Would there be any interest in a patch that would disable
> reconnects (controlled by sockopt) for ephemeral ports only?  I’m
> guessing that reconnecting mostly makes sense with well-known ports,
> so something like this may be of general interest?

If by ephemeral port you mean anything over 1024, then actually in most
applications I've seen it's always useful to reconnect, and the
existing option should be enough for those cases where it's not desired
- we don't want to duplicate functionality

> Thanks again!
> 
> Bill 
> 
> > On Sep 1, 2017, at 5:30 PM, Luca Boccassi 
> > wrote:
> > 
> > On Fri, 2017-09-01 at 16:59 -0400, Bill Torpey wrote:
> > > I'm curious about how ZMQ handles re-connection.  I understand
> > > that
> > > re-connection is supposed to happen "automagically" under the
> > > covers,
> > > but that poses an interesting question.
> > > 
> > > To make a long story short, the application I'm working on uses
> > > pub/sub sockets over TCP. and works like follows:
> > > 
> > > At startup:
> > > 1.  connects to a proxy/broker at a well-known address, using a
> > > pub/sub socket pair ("discovery");
> > > 2.  subscribes to a well-known topic using the "discovery" sub
> > > socket;
> > > 3.  binds a different pub/sub socket pair ("data") and retrieves
> > > the
> > > actual endpoints assigned;
> > > 4.  publishes the "data" endpoints from step 3 on the "discovery"
> > > pub
> > > socket; 
> > > 
> > > When the application receives a message on the "discovery" sub
> > > socket, it connects the "data" socket pair to the endpoints
> > > specified
> > > in the "discovery" message.
> > > 
> > > So far, this seems to be working relatively well, and allows the
> > > high-volume, low-latency "data" messages to be sent/received
> > > directly
> > > between peers, avoiding the extra hop caused by a proxy/broker
> > > connection.  The discovery messages use the proxy/broker, but
> > > since
> > > these are (very) low-volume the extra hop doesn't matter.  The
> > > use of
> > > the proxy also eliminates the "slow joiner" problem that can
> > > happen
> > > with other configurations.
> > > 
> > > My question is what happens when one of the "data" peer sockets
> > > disconnects.  Since ZMQ (apparently) keeps trying to reconnect,
> > > what
> > > would prevent another process from binding to the same ephemeral
> > > port?  
> > > 
> > > - Can I assume that if the new application at that port is not a
> > > ZMQ
> > > application, that the reconnect will (silently) fail, and
> > > continue to
> > > be retried?
> > 
> > The ZMTP handshake would fail, so yes.
> > 
> > > - What if the new application at that port *IS* a ZMQ
> > > application?  Would the reconnect succeed?  And if so, what would
> > > happen if it's a *DIFFERENT* ZMQ application, and the messages
> > > that
> > > it's sending/receiving don't match what the original application
> > > expects?
> > 
> > Depends on how you handle it in your application. If you have
> > security
> > concerns, then use CURVE with authentication so that only
> > authorised
> > peers can connect.
> > 
> > > It's reasonable for the application to publish a disconnect
> > > message
> > > when it terminates normally, and the connected peers can
> > > disconnect
> > > that endpoint.  But, applications don't always terminate normally
> > > ;-)
> > 
> > That's a common pattern. But the application needs to handle
> > unexpected
> > data somewhat gracefully. What that means is entirely up to the
> > application - as far as the library is concerned, if the handshake
> > succeeds then it's all good (hence the use case for CURVE).
> > 
> > > Any guidance, hints or tips would be much appreciated -- thanks
> > > in
> > > advance!
> > 
> > -- 
> > Kind regards,
> > Luca Boccassi___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org 
> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > 

Re: [zeromq-dev] ZMQ reconnect/ephemeral ports

[Bill Torpey]

Thanks Luca!  That was very helpful.

Although it leads to a couple of other questions:

- Can I assume that a ZMQ disconnect of a tcp endpoint would only occur if the 
underlying TCP socket is closed by the OS? Or are there conditions in which ZMQ 
will proactively disconnect the TCP socket and try to reconnect?

- I see that there is a sockopt (ZMQ_RECONNECT_IVL) that can be set to -1 to 
disable reconnection entirely.  In my case, the the “data” socket pair will 
*always* connect to an ephemeral port, so I *never* want to reconnect.  Would 
this be a reasonable option in my case, do you think?

- Would there be any interest in a patch that would disable reconnects 
(controlled by sockopt) for ephemeral ports only?  I’m guessing that 
reconnecting mostly makes sense with well-known ports, so something like this 
may be of general interest?

Thanks again!

Bill 

> On Sep 1, 2017, at 5:30 PM, Luca Boccassi  wrote:
> 
> On Fri, 2017-09-01 at 16:59 -0400, Bill Torpey wrote:
>> I'm curious about how ZMQ handles re-connection.  I understand that
>> re-connection is supposed to happen "automagically" under the covers,
>> but that poses an interesting question.
>> 
>> To make a long story short, the application I'm working on uses
>> pub/sub sockets over TCP. and works like follows:
>> 
>> At startup:
>> 1.  connects to a proxy/broker at a well-known address, using a
>> pub/sub socket pair ("discovery");
>> 2.  subscribes to a well-known topic using the "discovery" sub
>> socket;
>> 3.  binds a different pub/sub socket pair ("data") and retrieves the
>> actual endpoints assigned;
>> 4.  publishes the "data" endpoints from step 3 on the "discovery" pub
>> socket; 
>> 
>> When the application receives a message on the "discovery" sub
>> socket, it connects the "data" socket pair to the endpoints specified
>> in the "discovery" message.
>> 
>> So far, this seems to be working relatively well, and allows the
>> high-volume, low-latency "data" messages to be sent/received directly
>> between peers, avoiding the extra hop caused by a proxy/broker
>> connection.  The discovery messages use the proxy/broker, but since
>> these are (very) low-volume the extra hop doesn't matter.  The use of
>> the proxy also eliminates the "slow joiner" problem that can happen
>> with other configurations.
>> 
>> My question is what happens when one of the "data" peer sockets
>> disconnects.  Since ZMQ (apparently) keeps trying to reconnect, what
>> would prevent another process from binding to the same ephemeral
>> port?  
>> 
>> - Can I assume that if the new application at that port is not a ZMQ
>> application, that the reconnect will (silently) fail, and continue to
>> be retried?
> 
> The ZMTP handshake would fail, so yes.
> 
>> - What if the new application at that port *IS* a ZMQ
>> application?  Would the reconnect succeed?  And if so, what would
>> happen if it's a *DIFFERENT* ZMQ application, and the messages that
>> it's sending/receiving don't match what the original application
>> expects?
> 
> Depends on how you handle it in your application. If you have security
> concerns, then use CURVE with authentication so that only authorised
> peers can connect.
> 
>> It's reasonable for the application to publish a disconnect message
>> when it terminates normally, and the connected peers can disconnect
>> that endpoint.  But, applications don't always terminate normally ;-)
> 
> That's a common pattern. But the application needs to handle unexpected
> data somewhat gracefully. What that means is entirely up to the
> application - as far as the library is concerned, if the handshake
> succeeds then it's all good (hence the use case for CURVE).
> 
>> Any guidance, hints or tips would be much appreciated -- thanks in
>> advance!
> 
> -- 
> Kind regards,
> Luca Boccassi___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org 
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev 
> 
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZMQ reconnect/ephemeral ports

[Luca Boccassi]

On Fri, 2017-09-01 at 16:59 -0400, Bill Torpey wrote:
> I'm curious about how ZMQ handles re-connection.  I understand that
> re-connection is supposed to happen "automagically" under the covers,
> but that poses an interesting question.
> 
> To make a long story short, the application I'm working on uses
> pub/sub sockets over TCP. and works like follows:
> 
> At startup:
> 1.  connects to a proxy/broker at a well-known address, using a
> pub/sub socket pair ("discovery");
> 2.  subscribes to a well-known topic using the "discovery" sub
> socket;
> 3.  binds a different pub/sub socket pair ("data") and retrieves the
> actual endpoints assigned;
> 4.  publishes the "data" endpoints from step 3 on the "discovery" pub
> socket; 
> 
> When the application receives a message on the "discovery" sub
> socket, it connects the "data" socket pair to the endpoints specified
> in the "discovery" message.
> 
> So far, this seems to be working relatively well, and allows the
> high-volume, low-latency "data" messages to be sent/received directly
> between peers, avoiding the extra hop caused by a proxy/broker
> connection.  The discovery messages use the proxy/broker, but since
> these are (very) low-volume the extra hop doesn't matter.  The use of
> the proxy also eliminates the "slow joiner" problem that can happen
> with other configurations.
> 
> My question is what happens when one of the "data" peer sockets
> disconnects.  Since ZMQ (apparently) keeps trying to reconnect, what
> would prevent another process from binding to the same ephemeral
> port?  
> 
> - Can I assume that if the new application at that port is not a ZMQ
> application, that the reconnect will (silently) fail, and continue to
> be retried?

The ZMTP handshake would fail, so yes.

> - What if the new application at that port *IS* a ZMQ
> application?  Would the reconnect succeed?  And if so, what would
> happen if it's a *DIFFERENT* ZMQ application, and the messages that
> it's sending/receiving don't match what the original application
> expects?

Depends on how you handle it in your application. If you have security
concerns, then use CURVE with authentication so that only authorised
peers can connect.

> It's reasonable for the application to publish a disconnect message
> when it terminates normally, and the connected peers can disconnect
> that endpoint.  But, applications don't always terminate normally ;-)

That's a common pattern. But the application needs to handle unexpected
data somewhat gracefully. What that means is entirely up to the
application - as far as the library is concerned, if the handshake
succeeds then it's all good (hence the use case for CURVE).

> Any guidance, hints or tips would be much appreciated -- thanks in
> advance!

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] ZMQ reconnect/ephemeral ports

[Bill Torpey]

I'm curious about how ZMQ handles re-connection.  I understand that 
re-connection is supposed to happen "automagically" under the covers, but that 
poses an interesting question.

To make a long story short, the application I'm working on uses pub/sub sockets 
over TCP. and works like follows:

At startup:
1.  connects to a proxy/broker at a well-known address, using a pub/sub socket 
pair ("discovery");
2.  subscribes to a well-known topic using the "discovery" sub socket;
3.  binds a different pub/sub socket pair ("data") and retrieves the actual 
endpoints assigned;
4.  publishes the "data" endpoints from step 3 on the "discovery" pub socket; 

When the application receives a message on the "discovery" sub socket, it 
connects the "data" socket pair to the endpoints specified in the "discovery" 
message.

So far, this seems to be working relatively well, and allows the high-volume, 
low-latency "data" messages to be sent/received directly between peers, 
avoiding the extra hop caused by a proxy/broker connection.  The discovery 
messages use the proxy/broker, but since these are (very) low-volume the extra 
hop doesn't matter.  The use of the proxy also eliminates the "slow joiner" 
problem that can happen with other configurations.

My question is what happens when one of the "data" peer sockets disconnects.  
Since ZMQ (apparently) keeps trying to reconnect, what would prevent another 
process from binding to the same ephemeral port?  

- Can I assume that if the new application at that port is not a ZMQ 
application, that the reconnect will (silently) fail, and continue to be 
retried?

- What if the new application at that port *IS* a ZMQ application?  Would the 
reconnect succeed?  And if so, what would happen if it's a *DIFFERENT* ZMQ 
application, and the messages that it's sending/receiving don't match what the 
original application expects?

It's reasonable for the application to publish a disconnect message when it 
terminates normally, and the connected peers can disconnect that endpoint.  
But, applications don't always terminate normally ;-)

Any guidance, hints or tips would be much appreciated -- thanks in advance!




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

Re: [zeromq-dev] how to know how many packets/bytes passed through a ZMQ proxy

[Francesco]

2017-09-01 19:58 GMT+02:00 Luca Boccassi :
> The third parameter to zmq_proxy: http://api.zeromq.org/4-2:zmq-proxy
>
> If you pass a socket, all messages will be duplicated and sent to it.
> Then you can do all the measurements you need.
> Note that they are shallow refcounted copies, so only the small
> metadata is actually copied, not the payloads, so it's reasonably fast.

Ok thanks, I can try that!
Honestly however I think it would be nice to have an
easier/more-optimized way to retrieve such kind of informations...
maybe a message that is sent over a steerable proxy control socket (of
type REQ/REP maybe) or a socket option to retrieve via
zmq_get_socksockopt()

Thanks!

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

Re: [zeromq-dev] how to know how many packets/bytes passed through a ZMQ proxy

[Luca Boccassi]

On Fri, 2017-09-01 at 19:51 +0200, Francesco wrote:
> Hi Luca,
> 
> Which capture socket feature sorry?
> Do you mean the zmq socket monitor
> (http://api.zeromq.org/4-2:zmq-socket-monitor) ? In this case I don't
> know how to get notified about packets/bytes through that
> interface...
> (I'm using it to keep track of subscribers to my PUB sockets though)
> 
> Thanks,
> Francesco

The third parameter to zmq_proxy: http://api.zeromq.org/4-2:zmq-proxy

If you pass a socket, all messages will be duplicated and sent to it.
Then you can do all the measurements you need.
Note that they are shallow refcounted copies, so only the small
metadata is actually copied, not the payloads, so it's reasonably fast.

> 2017-09-01 19:40 GMT+02:00 Luca Boccassi :
> > On Fri, 2017-09-01 at 17:39 +0200, Francesco wrote:
> > > Hi all,
> > > 
> > > Is it possible to know (using the steerable proxy control socket
> > > perhaps?) the number of packets/bytes passed through a ZMQ proxy?
> > > 
> > > Thanks,
> > > Francesco
> > 
> > Hi,
> > 
> > No, but it should be easy to implement it in your application using
> > the
> > capture socket feature.
> > 
> > --
> > Kind regards,
> > Luca Boccassi
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] I need ZMQ server working like DLL

[Michal Vyskocil]

Hi,

The combination of zproject and czmq will do exactly what you want.
Zproject will generate build recipes for you in a way that code will be in
shared library. It can generate several targets including msvc project.

Czmq then provides zactor class, which allows you to implement your server
in thread in easiest way than pthreads or other interfaces. There are
several actors in czmq, like zproxy or zauth.

Them there is zpoller, simple pollen compatible with zeromq sockets, which
is the best way to implement timeouts.

https://github.com/zeromq/zproject
https://github.com/zeromq/czmq


Dne 31. 8. 2017 3:10 odpoledne napsal uživatel "Andy" <
borucki.andr...@gmail.com>:

I have two process. ZMQ server which is database client. Waits for requests
and read/write to database. ZMQ client works synchronously - give request
and short wait for response.
What example?
On github I saw many repositories for C++ ZeroMQ:
azmq
azmq1-0
cppzmq
libzmq
zeromq4-1
zmqpp
What difference is roughly between them ? Which would be better to me?
I don't use ZMQ_SUBSCRIBE?
How wait socker.recv only short time and next renew request?



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

Re: [zeromq-dev] how to know how many packets/bytes passed through a ZMQ proxy

[Francesco]

Hi Luca,

Which capture socket feature sorry?
Do you mean the zmq socket monitor
(http://api.zeromq.org/4-2:zmq-socket-monitor) ? In this case I don't
know how to get notified about packets/bytes through that interface...
(I'm using it to keep track of subscribers to my PUB sockets though)

Thanks,
Francesco



2017-09-01 19:40 GMT+02:00 Luca Boccassi :
> On Fri, 2017-09-01 at 17:39 +0200, Francesco wrote:
>> Hi all,
>>
>> Is it possible to know (using the steerable proxy control socket
>> perhaps?) the number of packets/bytes passed through a ZMQ proxy?
>>
>> Thanks,
>> Francesco
>
> Hi,
>
> No, but it should be easy to implement it in your application using the
> capture socket feature.
>
> --
> Kind regards,
> Luca Boccassi
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] how to know how many packets/bytes passed through a ZMQ proxy

[Luca Boccassi]

On Fri, 2017-09-01 at 17:39 +0200, Francesco wrote:
> Hi all,
> 
> Is it possible to know (using the steerable proxy control socket
> perhaps?) the number of packets/bytes passed through a ZMQ proxy?
> 
> Thanks,
> Francesco

Hi,

No, but it should be easy to implement it in your application using the
capture socket feature.

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] how to know how many packets/bytes passed through a ZMQ proxy

[Francesco]

Hi all,

Is it possible to know (using the steerable proxy control socket
perhaps?) the number of packets/bytes passed through a ZMQ proxy?

Thanks,
Francesco
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Crosstalk between sockets

[david . myers]

>>Can you upload a code snippet that reproduces the issue to
>>pastebin/gist/etc?

>>-- 
>>Kind regards,
>>Luca Boccassi

Thanks Luca, 

So the client threads look basically like this:- 

zmq::context_t context(1);
char szBuf[32];
// Start Image socket
m_socketImg = new zmq::socket_t(context, ZMQ_REP);
sprintf_s(szBuf, "tcp://*:%d", m_PortNumberImg); 

m_socketImg->bind(szBuf);
// Set timeout for Image socket
m_socketImg->setsockopt(ZMQ_RCVTIMEO, 1000); 

imageDataHeader ImageHeader;
zmq::message_t ImgHdr((void*), sizeof(ImageHeader),
(zmq::free_fn*)EmptyFreeFunct); 

 zmq::message_t ImgData;
 try
{
 m_socketImg->recv();
 }
 catch (...)
 {
 TRACE(_T("ZMQ Img error\n"));
 } 

 try
 {
m_socketImg->send(ImgAck);
  }
  catch (...)
  {
TRACE(_T("ZMQ Img Ack error\n"));
  } 

The server processes look like this:- 

char sImageUrl[32];
sprintf_s(sImageUrl, "tcp://localhost:%d", m_PortNumberImg); 

m_psocketImage = new zmq::socket_t (context, ZMQ_REQ);
m_psocketImage->setsockopt(ZMQ_SNDHWM, 100);
m_psocketImage->connect(sImageUrl);
m_psocketImage->setsockopt(ZMQ_RCVTIMEO, 1000); 

//now send image data
zmq::message_t imagemessage(imageData->pvData, imageDataLen,
empty_free, (void *));
 try
{
m_ZmqThread->m_psocketImage->send(imagemessage);
}
catch (const zmq::error_t& ze)
{
TRACE(("ZMQ error sending image data: %s\n"), ze.what());
} 

//wait for response (not required as we are now a ZMQ_PUSH)
zmq::message_t response;
try
{
bool bRet = m_ZmqThread->m_psocketImage->recv();
}
catch (const zmq::error_t& ze)
{
TRACE(_T("ZMQ error receiving image response: %ws\n"),
ze.what());
} 

The above REQ-REP code works well but when I rewrite it using PUSH-PULL
or PUB-SUB or PAIR (removing the Acknowledge code), the server processes
crash when the second one connects, after a number of frames. 

- David___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Crosstalk between sockets

[Luca Boccassi]

On Fri, 2017-09-01 at 11:21 +0100, david.my...@avalesta.com wrote:
> Hi, 
> 
> I am having trouble sending video packets from multiple server
> processes
> to a single client process with multiple threads. The client starts a
> new thread for each server it connects to, on a separate socket and
> port
> number. 
> 
> If I use REP-REQ and have the client acknowledge each packet, it
> works
> fine. 
> 
> As the packets are one way only (from server to client thread) I
> would
> like to use PUB-SUB or PUSH-PULL of even just PAIR, so that I don't
> have
> to acknolwledge each packet received by the client. However the
> server
> processes crash with "bad address" when I start more than one. It's
> as
> if there is some crosstalk or ineterference between the channels even
> though they use different ports and sockets. 
> 
> Any ideas or suggestions would be really great. 
> 
> Thanks

Can you upload a code snippet that reproduces the issue to
pastebin/gist/etc?

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Crosstalk between sockets

[david . myers]

Hi, 

I am having trouble sending video packets from multiple server processes
to a single client process with multiple threads. The client starts a
new thread for each server it connects to, on a separate socket and port
number. 

If I use REP-REQ and have the client acknowledge each packet, it works
fine. 

As the packets are one way only (from server to client thread) I would
like to use PUB-SUB or PUSH-PULL of even just PAIR, so that I don't have
to acknolwledge each packet received by the client. However the server
processes crash with "bad address" when I start more than one. It's as
if there is some crosstalk or ineterference between the channels even
though they use different ports and sockets. 

Any ideas or suggestions would be really great. 

Thanks___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Is shared ownership possible while sending with zero-copy?

[jricher]

I was working for Coroware on a similar project about 2.5 years ago. Even on 
lousy hardware, I was hitting link limits long before memory and allocations 
became an issue. 
While your mileage may vary, I suspect that zeromq will do well by you. 
Jacques Richer jric...@jricher.com(602)350-2463

 Original message From: Stephan Opfer  
Date: 9/1/17  12:22 AM  (GMT-07:00) To: zeromq-dev@lists.zeromq.org Subject: 
Re: [zeromq-dev] Is shared ownership possible while sending with
  zero-copy? 
Hi Patrik,

it is very likely to be a premature optimization, but on the other hand we 
would like to replace the ROS Middleware with a combination of Cap'n Proto and 
ZeroMQ. So I actually don't know which kind of messages the following 
generations are trying to send. We, that is the Carpe Noctem Cassel RoboCup 
team (www.das-lab.net).

We usually play with 5 robots connected over a local access point. Therefore, 
we use UDP Multicast. An "extrem" example would be the transfer of 2D laser 
scan data: 1080 * 8 byte = 8640 byte, 30 times per second = 253.125 KByte / 
sec. Or for debugging purpose the transfere of a live camera stream with 
roughly 900x900 pixels. The required amount of memory per transfered image 
depends on the compression. For raw images it is 46.35 MBytes / sec.

Greetings,
   Stephan

> I'm just curious, how large are those sensor values, how many do you keep 
> around, and to how many other robots do you intend to send them?

> Could it be premature optimization? Just asking because maybe it's not worth 
> the extra effort to make it zero-copy. Just copy and pass ownership to ZMQ.

> Regards, Patrik

> On 31 Aug 2017, at 20:06, Thomas Rodgers  wrote:
> 
> Unfortunately that's not possible, libzmq exposes only a C API, and even 
> though it is implemented in C++, it deliberately targets pre-C++11 compilers.
> 
> Further to the 'mark and sweep' idea, or more generally, deferred 
> reclamation. You could have the callback place the message to be freed on a 
> (possibly lock free, Boost has a handy one) queue and signal a 'reaper' 
> thread (waiting on a condition_variable). The reaper thread wakes up, 
> reclaims all queued message buffers then returns to waiting.
> 
>> On Thu, Aug 31, 2017 at 10:55 AM Stephan Opfer  
>> wrote:
>> > Another, more complicated way, would be to implement a mark
>> > garbage collector of sorts: instead of freeing the buffer, the callback
>> > you register with zmq_msg_init_data would mark the buffer as done (in a
>> > thread safe way!). Then your application's garbage collector can sweep
>> > it.
>> 
>> It would be nice, if I could pass over a copy  of (not reference or pointer 
>> to) a shared_ptr that owns the buffer, but with the call back and the "void 
>> * hint" this wasn't possible for me.
>> 
>> --
>> Distributed Systems Research Group
>> Stephan Opfer  T. +49 561 804-6280  F. +49 561 804-6277
>> Univ. Kassel,  FB 16,  Wilhelmshöher Allee 73,  D-34121 Kassel
>> WWW: http://www.uni-kassel.de/go/vs_stephan-opfer/
>> ___
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> ___
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
-- next part --
An HTML attachment was scrubbed...
URL: 


-- 
Distributed Systems Research Group
Stephan Opfer  T. +49 561 804-6280  F. +49 561 804-6277
Univ. Kassel,  FB 16,  Wilhelmshöher Allee 73,  D-34121 Kassel
WWW: http://www.uni-kassel.de/go/vs_stephan-opfer/
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Is shared ownership possible while sending with zero-copy?

[Stephan Opfer]

Hi Patrik,

it is very likely to be a premature optimization, but on the other hand we 
would like to replace the ROS Middleware with a combination of Cap'n Proto and 
ZeroMQ. So I actually don't know which kind of messages the following 
generations are trying to send. We, that is the Carpe Noctem Cassel RoboCup 
team (www.das-lab.net).

We usually play with 5 robots connected over a local access point. Therefore, we use UDP 
Multicast. An "extrem" example would be the transfer of 2D laser scan data: 
1080 * 8 byte = 8640 byte, 30 times per second = 253.125 KByte / sec. Or for debugging 
purpose the transfere of a live camera stream with roughly 900x900 pixels. The required 
amount of memory per transfered image depends on the compression. For raw images it is 
46.35 MBytes / sec.

Greetings,
  Stephan


I'm just curious, how large are those sensor values, how many do you keep 
around, and to how many other robots do you intend to send them?



Could it be premature optimization? Just asking because maybe it's not worth 
the extra effort to make it zero-copy. Just copy and pass ownership to ZMQ.



Regards, Patrik



On 31 Aug 2017, at 20:06, Thomas Rodgers  wrote:

Unfortunately that's not possible, libzmq exposes only a C API, and even though 
it is implemented in C++, it deliberately targets pre-C++11 compilers.

Further to the 'mark and sweep' idea, or more generally, deferred reclamation. 
You could have the callback place the message to be freed on a (possibly lock 
free, Boost has a handy one) queue and signal a 'reaper' thread (waiting on a 
condition_variable). The reaper thread wakes up, reclaims all queued message 
buffers then returns to waiting.


On Thu, Aug 31, 2017 at 10:55 AM Stephan Opfer  
wrote:
> Another, more complicated way, would be to implement a mark
> garbage collector of sorts: instead of freeing the buffer, the callback
> you register with zmq_msg_init_data would mark the buffer as done (in a
> thread safe way!). Then your application's garbage collector can sweep
> it.

It would be nice, if I could pass over a copy  of (not reference or pointer to) a 
shared_ptr that owns the buffer, but with the call back and the "void * hint" 
this wasn't possible for me.

--
Distributed Systems Research Group
Stephan Opfer  T. +49 561 804-6280  F. +49 561 804-6277
Univ. Kassel,  FB 16,  Wilhelmshöher Allee 73,  D-34121 Kassel
WWW: http://www.uni-kassel.de/go/vs_stephan-opfer/
___
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

-- next part --
An HTML attachment was scrubbed...
URL: 


--
Distributed Systems Research Group
Stephan Opfer  T. +49 561 804-6280  F. +49 561 804-6277
Univ. Kassel,  FB 16,  Wilhelmshöher Allee 73,  D-34121 Kassel
WWW: http://www.uni-kassel.de/go/vs_stephan-opfer/
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev