On 10 June 2013 11:37, Parag Patel <[email protected]> wrote: > Does multicast loopback work without known issues on linux (regardless > of java or not)? **** > > > If you start the subscriber before the publisher it relies on undefined behaviour but works. The subscriber would thus see unicast packets and the IP stack would not duplicate to the publisher.
If the publisher started first it would bind to the socket and thus only achieve unreliable delivery. You can verify with a debug build and the following: publisher: $ *./daytime -lp 7500 -n "eth0;"* subscriber: $ *PGM_LOSS_RATE=25 ./purinrecv -lp 7500 -n "eth0;"* Set trace level logging to verify NAKs, in the publish-started-first case it would appear similar to: $ *PGM_MIN_LOG_LEVEL=TRACE PGM_LOSS_RATE=25 ./purinrecv -lp 7500 -n "eth0;"* ... "Mon, 10 Jun 2013 12:28:41 -0400" (32 bytes from 167.203.253.7.192.148.30861) Trace: Recv again on not-full Trace: Recv again on not-full Trace: Recv again on not-full Trace: Recv again on not-full Trace: Recv again on not-full Trace: nak_rpt_expiry in 2.000000 seconds. Trace: NAK backoff queue empty. Trace: Recv again on not-full Trace: Recv again on not-full Trace: Recv again on not-full Trace: New pending data. Trace: Recv again on not-full Trace: Recv again on not-full Trace: Recv again on not-full Trace: Recv again on not-full Trace: New pending data. Trace: Recv again on not-full Trace: NCF retry #11 attempt 1/50. /* NCF retry queue not-empty */ Trace: Wait ncf queue empty. Trace: nak_rpt_expiry in 2.000000 seconds. Trace: NAK backoff queue empty. Trace: Recv again on not-full Trace: Recv again on not-full Trace: Recv again on not-full Trace: Recv again on not-full Trace: Recv again on not-full Trace: nak_rpt_expiry in 2.000000 seconds. Trace: NAK backoff queue empty. *Trace: Discarded unknown PGM packet. /* receipt of NAK in subscriber */* -- Steve-o
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
