2012/10/13 Pieter Hintjens piet...@gmail.com:
On Oct 12, 2012 6:32 PM, andrea crotti andrea.crott...@gmail.com wrote:
But why double binding on IPC doesn't fail, when should that be a good idea?
The code explicitly overrides an existing binding on an IPC endpoint
so it can recover after a
It's a long-standing bug that is very difficult to fix. The work around is to
do as you discovered which is *always bind first* and then connect when using
inproc transport.
For details as to why this is hard, try searching the mailing list archive. The
answer would have been given by Martin
Hi Kahn-Chan,
It's a feature - inproc transport doesn't supported unordered bind or
connect. A map of endpoints are maintained per context - you'll get that
error if and when there's no bound address when trying to connect.
- Lourens
On Thu, Oct 18, 2012 at 5:55 PM, Kah-Chan Low
Thanks Chuck and Lourens for your very speedy reply!
I have two threads and to overcome this problem I have set-up the code like
this:
Thread A is guaranteed to execute the relevant parts of the code first even
before Thread B gets started.
Thread A
--
.
.
Hi all,
I'm trying to get a small client-server test program working using
multicast sockets:
http://pastebin.com/h5T1AvwS
This program works fine with tcp sockets but fails to run over epgm
sockets. When I use Wireshark, I do see the server sending packets to
the multicast group address but
On 18 October 2012 18:13, Thomas Loockx thomas.loo...@otoy.com wrote:
Further investigation shows that on the server side IGMP joins are
received to join the multicast group. And I can see the multicast
traffic on the client side as well. It seems that the multicast
traffic is not picked up
On Thu, Oct 18, 2012 at 5:53 AM, Pieter Hintjens p...@imatix.com wrote:.
The wait is in socket_base.cpp:send, where it says:
// Oops, we couldn't send the message. Wait for the next
// command, process it and try to send the message again.
// If timeout is reached in the
I've enabled debugging in openpgm, but it outputs not much really:
arg: client
Running as client
Minor: OpenPGM 5.1.118 (1369) 2012-10-18 17:56:46 Linux x86_64
Minor: Detected 4 available 4 online 4 configured CPUs.
Minor: Using TSC timer.
Minor: TSC frequency set to 1200 MHz
Trace: Opening UDP
On Thu, Oct 18, 2012 at 9:32 PM, andrea crotti
andrea.crott...@gmail.com wrote:
I think it should or raise a warning saying that the IPC file already
exists..
Right.
What's the difference between IPC and TCP in terms of recovering after
a crash? Maybe the TCP port gets closed anyway and
Ok, I figured it out.
It looks like Centos 5.5 is blocking multicast traffic. Tweaking
iptables made my app work.
thanks,
Thomas
On Fri, Oct 19, 2012 at 12:07 PM, Thomas Loockx thomas.loo...@otoy.com wrote:
I've enabled debugging in openpgm, but it outputs not much really:
arg: client
On Fri, Oct 19, 2012 at 7:49 AM, Ian Barber ian.bar...@gmail.com wrote:
Hmm, I'm wondering if in the XSEND we need to use EHOSTUNREACH or similar,
and turn that into an EAGAIN in send to avoid this. Problem is that spills
the mandatory flag out to the socket_base as well as router. Right the
On Thu, Oct 18, 2012 at 8:02 PM, Pieter Hintjens p...@imatix.com wrote:
I like that... EAGAIN is really the wrong value to use, EHOSTUNREACH
is much nicer. At the API level too. It's not an EAGAIN error at all,
it's the address you used does not exist...
-Pieter
Thinking about it, I
On Thu, Oct 18, 2012 at 3:45 PM, Chuck Remes li...@chuckremes.com wrote:
No, it is not guaranteed that socket3 will be ready for a connection. All
binds (and connects) happen asynchronously in the I/O thread. Depending on
your machine performance, it could be ready in 10ms, 100ms or more.
On Fri, Oct 19, 2012 at 8:16 AM, Apostolis Xekoukoulotakis
xekou...@gmail.com wrote:
I would like to know when it is possible to pass a socket without creating
problems?
You're using CZMQ, I assume...?
You can pass a socket from one thread to another if you do not use it
in the original
On Fri, Oct 19, 2012 at 6:48 AM, Thomas Loockx thomas.loo...@otoy.com wrote:
As a side note, is it possible to include a full working multicast
example in The Guide?
Great idea! ... I've not dug into multicast enough myself, but if you
would like to make a minimal example in the style of the
On Fri, Oct 19, 2012 at 12:37 PM, Ian Barber ian.bar...@gmail.com wrote:
Thinking about it, I believe the original patch had it as a EHOSTUNREACH -
it got changed to a EAGAIN and I don't specifically recall the reason why -
I'll have to look back over the commit history.
Changed on June
On Fri, Oct 19, 2012 at 1:39 PM, Ian Barber ian.bar...@gmail.com wrote:
Yeah, I have no problem going back to EHOSTUNREACH. Looking back at the PR,
the idea of the change was pretty much precisely to allow a blocking send to
a currently disconnected host (which is now what you're running up
17 matches
Mail list logo
