[zeromq-dev] UDP message with zeromq 2.0beta

Guo, Yanchao Yanchao.Guo at sac.com
Thu Jan 21 11:19:23 CET 2010


Thanks Martin. 

I have another question regarding PGM. in http://www.zeromq.org/whitepapers:design-v05, it stated that 

Comment: On Linux, PGM-enabled applications have to be run with root privileges. The cause is that there is no PGM implementation in the kernel and you have to send/receive PGM packets from the user space. Manipulation of raw IP sockets from user space requires root privileges. If you want to use multicast without root privileges you have to use PGM encapsulated within UDP (use say "bp/pgm://udp:eth0;224.0.0.0:5555" instead of "bp/pgm://eth0;224.0.0.0:5555"). Note that this is not the real PGM, i.e. it won't intercommunicate with other PGM implementations. Also, you have to set these two environment variables:

$ export PGM_TIMER="TSC"
$ export PGM_SLEEP="TSC"


Is this still valid? I the the address specification bp/pgm://udp:eth0;224.0.0.0:5555 but it gives me exception: 

terminate called after throwing an instance of 'zmq::error_t'
  what():  Protocol not supported
Aborted



-----Original Message-----
From: Martin Sustrik [mailto:sustrik at 250bpm.com]
Sent: Thu 1/21/2010 5:10 AM
To: Guo, Yanchao
Cc: zeromq-dev at lists.zeromq.org
Subject: Re: [zeromq-dev] UDP message with zeromq 2.0beta
 
Martin Sustrik wrote:
> Guo, Yanchao wrote:
>> thanks Martin. I put it into a endless loop and I can see that there is 
>> no packet drop for my local testing.
>>
>> Is there a way to flush the sending thread before program exist?
> 
> No there isn't. There are several reasons for that design:
> 
> 1. Say you are using TCP transport, the connection is broken and there 
> are 1000 messages queued for sending. Flushing would deadlock in such 
> situation.
> 
> 2. With PGM transport, even if you flush messages to the network, 
> there's no guarantee that some packets won't get dropped (by switch or 
> whatever networking device). While consumer may detect the lost and ask 
> for retransmit, the sender will be closed once the retransmit request 
> arrives. Thus, flushing the messages doesn't solve the problem anyway.

The best thing you can do IMO is to wait for few seconds before exiting 
the sender application. This "sefaguard interval" can be though of as a 
timeout, time given to consumer applications to sort out all the 
remaining business they have to accomplish with the sender.

HTH.
Martin



DISCLAIMER: This e-mail message and any attachments are intended solely for the use of the individual or entity to which it is addressed and may contain information that is confidential or legally privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and permanently delete this message and any attachments. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100121/c76d4a59/attachment.htm>


More information about the zeromq-dev mailing list