whm2300 / openpgm Goto Github PK

What steps will reproduce the problem?
1. ran ./configure
2. ran make

What is the expected output? What do you see instead?
In file included from ./include/impl/sockaddr.h:38,
                 from ./include/impl/notify.h:46,
                 from ./include/impl/framework.h:66,
                 from thread.c:23:
./include/pgm/in.h:34: error: redefinition of ‘struct group_req’
./include/pgm/in.h:40: error: redefinition of ‘struct group_source_req’
make: *** [libpgm_noinst_la-thread.lo] Error 1

What version of the product are you using? On what operating system?
Version 5.1.118 on Mac OS X Lion i7 Processor

Please provide any additional information below.

On Linux box is started an PGM sender that does chunking for approx. 1MB buffer 
into chunks of 1500 bytes and then tries to send these chunks to the PGM 
receiver on another Linux Box (also using Ubuntu 11.04).  
2. The receiver ends up with IO_STATUS_RESET. How to recover from this? 
In general, expected is that whole buffer is completely transferred.
This is not the case. My question is how the PGM receiver can send  NAK to the 
sender?

Seems to me reasonable that receiver in such case sends NAK as unicast message. 
How to do this? Finally, how PGM sender knows which packets should retransmit. 
In other words how to properly retransmit packets?

I'm using OpenPGM 5.1.118,  Ubuntu 11.04

An example showing how PGM receiver could send NAK to the PGM sender 
(preferably using unicast) would be of great help.
Thanks in advance.

What steps will reproduce the problem?
1. libpgm-5.1.115
2. ./configure --with-pgm
3. make

What is the expected output? What do you see instead?
Fails to build with redefined struct error and missing define.

What version of the product are you using? On what operating system?
libpgm-5.1.115, OS X, 10.7

Please provide any additional information below.
To fix the build I added the following, works but might well need to be cleaned 
up..








--- libpgm-5.1.115~dfsg/openpgm/pgm/recv.c  2011-03-23 17:43:15.000000000 +1100
+++ libpgm-5.1.115~dfsg.mod/openpgm/pgm/recv.c  2011-08-11 20:45:08.000000000 
+1000
@@ -23,6 +23,10 @@
 #  define _GNU_SOURCE
 #endif

+#if defined(__APPLE__) && __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1070
+#define __APPLE_USE_RFC_3542  1
+#endif
+
 #include <errno.h>
 #ifndef _WIN32
 #  include <sys/types.h>




--- libpgm-5.1.115~dfsg/openpgm/pgm/include/pgm/in.h    2011-03-23 
17:43:10.000000000 +1100
+++ libpgm-5.1.115~dfsg.mod/openpgm/pgm/include/pgm/in.h    2011-08-11 
20:44:26.000000000 +1000
@@ -29,6 +29,7 @@
 #include <sys/socket.h>
 #include <pgm/types.h>

+#if !defined(__APPLE__) || (defined(__APPLE__) && 
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 1070)
 /* sections 5 and 8.2 of RFC 3768: Multicast group request */
 struct group_req
 {
@@ -42,6 +43,7 @@
    struct sockaddr_storage gsr_group;  /* group address */
    struct sockaddr_storage gsr_source; /* group source */
 };
+#endif

 PGM_BEGIN_DECLS

What steps will reproduce the problem?
1. Compile a program that includes package.h with g++ and -pedantic turned on

What is the expected output? What do you see instead?
Obviously, success is expected. Instead you see:
/usr/include/pgm-5.1/pgm/packet.h:223:19: error: ISO C++ forbids zero-size 
array 'opt_sqn' [-Werror=edantic]

Now, without -pedantic on you are likely to have a successful compile but a 
subtle bug.

What version of the product are you using? On what operating system?
I'm using libpgm-5.1.118. This is on SmartOS, but I'm sure I can reproduce it 
on other platforms, including Linux.

Please provide any additional information below.

The problem is right here:


/* 9.3.5.  Option NAK List - OPT_NAK_LIST
 *
 * GNU C allows opt_sqn[0], ISO C89 requireqs opt_sqn[1], ISO C99 permits opt_sqn[]
 */
struct pgm_opt_nak_list {
        uint8_t         opt_reserved;           /* reserved */
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
/* C99 flexible array, sizeof() invalid */
        uint32_t        opt_sqn[];              /* requested sequence number [62] */
#elif !defined(__STDC_VERSION__) || defined(__cplusplus)
/* C90 and older */
        uint32_t        opt_sqn[1];
#else
/* GNU C variable-length object */
        uint32_t        opt_sqn[0];
#endif
};

While ISO C99 permits VLA's, it isn't supported by C++, and a lot of C++ 
compilers when compiling for C++. Since this header could and should be 
included by a C++ program this is relevant. The proper logic is to test for C++ 
and for a __STDC_VERSION__ flag (which is set by gcc, even when compiling C++ 
code) before testing for anything else. Revised code looks like:


/* 9.3.5.  Option NAK List - OPT_NAK_LIST                                       

 *                                                                                                    
 * GNU C allows opt_sqn[0], ISO C89 requireqs opt_sqn[1], ISO C99 permits opt_sqn[]                   
 */
struct pgm_opt_nak_list {                                                       

    uint8_t     opt_reserved;       /* reserved */                                                    
#if defined(__cplusplus) || !defined(__STDC_VERSION__)                          

    uint32_t    opt_sqn[1];                                                                           
#elif (__STDC_VERSION__ >= 199901L)                                             

/* C99 flexible array, sizeof() invalid */                                      

    uint32_t    opt_sqn[];      /* requested sequence number [62] */                                  
#else                                                                           

/* GNU C variable-length object */                                              

    uint32_t    opt_sqn[0];                                                                           
#endif                                                                          

};

I want to use develop 'off-line' but I can not find a method of downloading
the documentation. There seems to be plenty of documentation within the
wiki but this is several individual web pages.

What steps will reproduce the problem?
1. Make a new blocking socket. I'm using the socket to send, but I believe I 
need to call recv on it to handle acks and naks.
2.call pgm_recv with MSG_DONTWAIT const int status = pgm_recv(sock, buf, 
sizeof(buf), MSG_DONTWAIT, &len, &pgm_err);
3.

What is the expected output? What do you see instead?
I expect it to return with E_WOULDBLOCK (or the PGM version of that flag)


What version of the product are you using? On what operating system?
Linux amd64

Please provide any additional information below.

in the pgm_recvmsgv function there is:
len = recvskb (sock,
               sock->rx_buffer,     /* PGM skbuff */
               0,
               (struct sockaddr*)&src,
               sizeof(src),
               (struct sockaddr*)&dst,
               sizeof(dst));

I think that 0 should be flags which is passed into pgm_recvmsgv. This is 
around line 761.

Also in recvskb there is a call to:
const ssize_t len = recvfrom (sock->recv_sock, skb->head, sock->max_tpdu, 0, 
src_addr, &fromlen);

That 0 should also be flags which is passed in. This is around line 108.

Have a set up where I'm using OpenPGM on the server-side, MS-PGM on the 
client-side trying to multicast a large file.  What I'm running into is an odd 
performance problem when trying to increase the speed.

For example (on the sender):
PGM_MTU: 7500
PGM_TXW_MAX_RTE: 7,000,000

Operates as I would expect, with an approx. speed of ~7000KB/sec

However, when I change PGM_TXW_MAX_RTE to 8,000,000, the rate drops to the 
floor.  It's not the repair cycle or anything, it's the rate of packets coming 
from the sender.  If I increase the PGM_MTU value to 9000, then performance 
picks back up.

Looking at the code, I think the problem is in the calculations done during 
setup in the rate engine.  Specifically, looking at pgm_rate_create in 
rate_control.c, I see:

    if ((rate_per_sec / 1000) >= max_tpdu) {
        bucket->rate_per_msec   = bucket->rate_per_sec / 1000;
        bucket->rate_limit  = bucket->rate_per_msec;
    } else {
        bucket->rate_limit  = bucket->rate_per_sec;
    }

My first impression is that bucket->rate_limit is being set wrong, shouldn't 
that be bucket->rate_limit = bucket->rate_per_sec?

The basic work flow for the sending loop (non-blocking) is to send, check the 
status code, and in the case of PGM_IO_STATUS_RATE_LIMITED, use pgm_getsockopt 
to fetch PGM_RATE_REMAIN.  Once PGM_TXW_MAX_RTE/1000 is >= PGM_MTU, the values 
returned skyrocket, causing the sender to slow down greatly.

So I'm trying to figure out if this is a.) a mistake on our part with the 
program flow, or b.) a bug in OpenPGM.

Additional bit:
- server is running on FreeBSD 7.0
- we're using libpgm-5.2.122
- client is running on Windows 7 using MS-PGM

Thanks,

Jon

(Chasing something down a rabbit hole.) As per this issue over at homebrew:
https://github.com/mxcl/homebrew/issues/14210#issuecomment-7828404

Anything that can be done to fix this?

The rpmlint utility indicates an issue with openpgm's use of setuid().

Quoting from "rpmlint -I missing-call-to-setgroups-before-setuid"

This executable is calling setuid and setgid without setgroups or initgroups. 
There is a high probability this means it didn't relinquish all groups, and 
this would be a potential security issue to be fixed. Seek POS36-C on the web 
for details about the problem.

I'm attaching a patch against SVN trunk (r1508 at the time of writing)

For a commit log, you can use the following text:

When dropping privileges from root, the `setgroups` call will remove any 
extraneous groups. If we don't call this, then even though our uid has dropped, 
we may still have groups that enable us to do super-user things.

HAVE_HOST_ORDER_IP_LEN and HAVE_HOST_ORDER_IP_OFF used in packet_parse.c are 
not detected correctly.  This may vary based on version, packaging, or 
configure vs. scons.  

For example:

=========
root@pgm-test-1:~/libpgm-5.1.118-1~dfsg/openpgm/pgm# ./configure | grep 'host 
byte'
checking for raw IP sockets ip_{len,off} host byte ordering... no

root@pgm-test-1:~/libpgm-5.2.122/openpgm/pgm# ./configure | grep 'host byte'
checking for raw IP sockets ip_{len,off} host byte ordering... no

root@pgm-test-1:~/libpgm-5.2.122/openpgm/pgm# scons WITH_GLIB=true 
WITH_GETTEXT=true 2>&1 | egrep '(HAVE_HOST|host byte)'
Checking for raw IP sockets ip_{len,off} host byte ordering...yes
Checking for raw IP sockets ip_{len,off} host byte ordering...yes

root@pgm-test-1:~/openpgm-read-only/openpgm/pgm# scons WITH_GLIB=true 
WITH_GETTEXT=true 2>&1 | grep 'host byte'
Checking for raw IP sockets ip_{len,off} host byte ordering...yes
Checking for raw IP sockets ip_{len,off} host byte ordering...yes
=========

When built on my systems using scons, I can not send and receive using 
pgmsend/pgmrecv.

Platforms:

=========
Linux pgm-test-1 3.5.0-26-generic #42~precise1-Ubuntu SMP Mon Mar 11 22:19:42 
UTC 2013 i686 i686 i386 GNU/Linux

Linux pgm-test-0 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 
x86_64 x86_64 x86_64 GNU/Linux
=========

When running with debug logging on, this is printed:

=========
2013-04-07 01:24:45 pgm-test-1 Pgm: Debug: pgm_parse_raw (skb:0x872fb38 
dst:0xb7292c3c error:0xb729278c)
2013-04-07 01:24:45 pgm-test-1 Pgm: Trace: Discarded invalid packet: IP packet 
received at 64 bytes whilst IP header reports 16384 bytes.
2013-04-07 01:24:45 pgm-test-1 Pgm: Debug: recvskb (sock:0x872e1a8 
skb:0x872fb38 flags:0 src-addr:0xb7292bbc src-addrlen:128 dst-addr:0xb7292c3c 
dst-addrlen:128)
=========

This looked odd, and I suspected a byte ordering issue.  An analysis of the 
code shows two #ifdefs around these config options that toggle the use of 
ntohs().  Their origin is traced back to SConscript.autoconf:

=========
# IP header order as per IP(4) on FreeBSD
def CheckIpLengthHostOrder (context):
        context.Message ('Checking for raw IP sockets ip_{len,off} host byte ordering...');
        source = """
int
main ()
{
#if defined( __APPLE__ ) || defined( __NetBSD__ ) || defined( __FreeBSD__ )
        fail fail fail
#endif
        return 0;
}
        """
        result = context.TryCompile (source, '.c');
        context.Result (result);
        return result;

def CheckIpOffsetHostOrder (context):
        return CheckIpLengthHostOrder (context);
=========

This appears to simply be platform define-based.  I don't think this is 
correct, because when I make the check fail for my platform, recompile with 
scons, and rerun my test it works correctly:

=========
2013-04-07 01:29:06 pgm-test-1 Pgm: Trace: Recv again on not-full
2013-04-07 01:29:06 pgm-test-1 Pgm: Debug: recvskb (sock:0x9c581a8 
skb:0xb6901648 flags:0 src-addr:0xb7233bbc src-addrlen:128 dst-addr:0xb7233c3c 
dst-addrlen:128)
2013-04-07 01:29:06 pgm-test-1: (12 bytes)
2013-04-07 01:29:06 pgm-test-1:     0: "please work" (12 bytes from 
133.21.200.234.76.178.34920)
2013-04-07 01:29:06 pgm-test-1 Pgm: Debug: pgm_recvmsgv (sock:0x9c581a8 
msg-start:0xb7233cf0 msg-len:20 flags:0 bytes-read:0xb72342f4 error:0xb72342f8)
2013-04-07 01:29:06 pgm-test-1 Pgm: Debug: recvskb (sock:0x9c581a8 
skb:0xb6901648 flags:0 src-addr:0xb7233bbc src-addrlen:128 dst-addr:0xb7233c3c 
dst-addrlen:128)
=========

I believe this check needs to be fixed.

environment : 
Linux : 2.6.18-164.11.1.el5
openpgm version : openpgm-5.1.118 

Can someone please help with the following issue : 

when we do select on read operation on  pgmsocket (pgmsocket is set at blocking 
mode ) and linux pipes, if there is not pgmdata, the select seems to be able to 
correctly return with pipe socketId set (if there is incoming data in pipe). 

However, if there is incoming data for pgmsocket, when select returns, it only 
captures socektId for pgmsocket, not pipe socketId, even though there is 
incoming data for the pipe.

Thanks,
Frank

Do you have any documentation for this project ?

I was able to compile the code but don't know how to test it or how to test it ?

Does it produces any binary file ?
How do I compile the example code.

Please provide some basic documentation.

Thanks

What steps will reproduce the problem?
 -- Create GSI with pgm_gsi_create_from_string

What is the expected output? What do you see instead?
 -- According to the documentation, it should be possible to call it with a const char* null-terminated string and length 0, but my program asserts on "(pgm_gsi_create_from_data): assertion `length > 1' failed"

What version of the product are you using? On what operating system?
pgm 5.1 official Ubuntu repository

if.c, line 520:

const int eai = getaddrinfo (ifname, NULL, &hints, &result);

On Ubuntu 14.04 under mysterious circumstances it returns -3 (EAI_AGAIN) with 
ifname = "eth0". DHCP was switched off, if it matters.
I suggest to add "case EAI_AGAIN:" under "case EAI_NONAME:":

#if defined(EAI_NODATA) && EAI_NODATA != EAI_NONAME
        case EAI_NODATA:
#endif
        case EAI_AGAIN:
        case EAI_NONAME:
            check_ifname = TRUE;
            break;

After this fix, ZeroMQ successfully connects to epgm://eth0;239.192.1.1.

What steps will reproduce the problem?
1.  Could only reproduce from another using. framework (libzmq)

The issue was called out here in libzmq: but was not actually their issue.

https://zeromq.jira.com/browse/LIBZMQ-296

The issue is in the rand.c file in the pgm_rand_create 
60 PGM_GNUC_INTERNAL
 61 void
 62 pgm_rand_create (
 63         pgm_rand_t*     new_rand
 64         )
 65 {
 66 /* pre-conditions */
 67         pgm_assert (NULL != new_rand);
 68 
 69 #ifndef _WIN32
 70 /* attempt to read seed from kernel
 71  */
 72         FILE* fp;
 73         do {
 74                 fp = fopen ("/dev/urandom", "rb");
 75         } while (PGM_UNLIKELY(EINTR == errno));
 76         if (fp) {
 77                 size_t items_read;
 78                 do {
 79                         items_read = fread (&new_rand->seed, sizeof(new_rand->seed), 1, fp);
 80                 } while (PGM_UNLIKELY(EINTR == errno));
 81                 fclose (fp);
 82                 if (1 == items_read)
 83                         return;
 84         }
 85 #endif /* !_WIN32 */
 86         const pgm_time_t now = pgm_time_update_now();
 87         new_rand->seed = (uint32_t)pgm_to_msecs (now);
 88 }


The issue of course is this bit right here:


73         do {
74                 fp = fopen ("/dev/urandom", "rb");
75         } while (PGM_UNLIKELY(EINTR == errno));

The author is NOT checking that the value of fp is in error (ie fp != NULL). If 
errno has some garbage value from some other error, this do while will loop 
forever until it runs out of file descriptors per the process ulimit on the 
system (mine being 1024).

I was able to get by, by changing:


- 75         } while (PGM_UNLIKELY(EINTR == errno));

+ 75         } while ((fp == NULL) && (PGM_UNLIKELY(EINTR == errno)));

This is probably sub-optimal and not the best solution, but given it's a 
function which returns void I wasn't sure as to the best approach for 
signalling error back to the user.

Thanks

Is it possible to determine on the receiver side if a session has ended (i.e., 
sending app closed the socket or the session timed out)?
I see that PGM_IO_STATUS_FIN is defined but not used in the implementation.

What version of the product are you using? On what operating system?

libpgm-5-1-118

What steps will reproduce the problem?
1. call pgm_bind3 with a sockaddr that has sockaddr->sa_addr.sport set to a 
value
2. in socket.c line 2029, it calls htons on that port value, thus reversing it. 
The sport in a sockaddr should already be assumed to be in network byte order


What is the expected output? What do you see instead?
I expect the tsi to use the port value I specified

What version of the product are you using? On what operating system?
linux/windows, openpgm 5.1.118

Please provide any additional information below.
change socket.c line 2029 from:
    sock->tsi.sport = htons (sock->tsi.sport);
to 
    sock->tsi.sport = sock->tsi.sport;

What is the recommended way of handling protocol events in a send-only 
application?

Suppose I have a publishing thread that sends some data in a loop. According to 
the docs I must also call one of the receive functions periodically in order to 
advance the pgm state machine. Would it be acceptable if I have a separate 
thread that just calls one of the receive functions in a loop (on the same 
socket)? Will a blocking call do in this case?

void evenProcessinfThread()
{
  for(;;)
  {
    pgm_recv(...);
  }
}

What version of the product are you using? On what operating system?
libpgm-5.1.118

Env: Win7 + MinGW64(gcc4.8.2)

Reproducing Steps:
1. open a MSYS shell, cd into pgm folder(libpgm-5.2.122/openpgm/pgm)
2. run "./configure"
3. run "make"

The detailed compilation output:

$ make
  CC     libpgm_noinst_la-thread.lo
  CC     libpgm_noinst_la-mem.lo
  CC     libpgm_noinst_la-string.lo
  CC     libpgm_noinst_la-list.lo
  CC     libpgm_noinst_la-slist.lo
  CC     libpgm_noinst_la-queue.lo
  CC     libpgm_noinst_la-hashtable.lo
  CC     libpgm_noinst_la-messages.lo
  CC     libpgm_noinst_la-error.lo
  CC     libpgm_noinst_la-math.lo
  CC     libpgm_noinst_la-packet_parse.lo
  CC     libpgm_noinst_la-packet_test.lo
  CC     libpgm_noinst_la-sockaddr.lo
  CC     libpgm_noinst_la-time.lo
  CC     libpgm_noinst_la-if.lo
if.c: In function 'parse_interface':
if.c:380:16: error: 'AI_ADDRCONFIG' undeclared (first use in this function)
    .ai_flags = AI_ADDRCONFIG | AI_NUMERICHOST /* AI_V4MAPPED is unhelpful */
                ^
if.c:380:16: note: each undeclared identifier is reported only once for each 
function it appears in
if.c: In function 'parse_group':
if.c:974:15: error: 'AI_ADDRCONFIG' undeclared (first use in this function)
   .ai_flags = AI_ADDRCONFIG, /* AI_V4MAPPED is unhelpful */
               ^
make: *** [libpgm_noinst_la-if.lo] Error 1

I built libpgm 5.2.122 on Ubuntu 12.10 x86_64 with this command:

        cons WITH_HTTP=true BUILD=debug


I modified the purinrecv.c example to call pgm_http_init just after pgm_init:

        if (!pgm_http_init (PGM_HTTP_DEFAULT_SERVER_PORT, &pgm_err)) {
                fprintf (stderr, "Unable to start PGM http: %s\n", pgm_err->message);
                pgm_error_free (pgm_err);
                return EXIT_FAILURE;
        }


When I go to http://localhost:4968 in my browser, the http thread hangs on the 
call to 
pgm_rwlock_reader_lock (&pgm_sock_list_lock) in index_callback.

After some debugging, I realized my config.h contains #define 
USE_DUMB_RWSPINLOCK 1.  This causes engine.c to initialize pgm_sock_list_lock 
as a spinlock (pgm_rwspinlock_init).  

But http.c does not include config.h, so USE_DUMB_RWSPINLOCK is not defined 
with http.c is compiled.  So the call to pgm_rwlock_reader_lock 
(&pgm_sock_list_lock) from http.c calls pthread_rwlock_rdlock, which does not 
work on the spinlock.

Adding #include <config.h> to the top of http.c fixes this.  I'm attaching my 
modified version of http.c

I am currently doing some performance tests for OpenPGM. I now have a problem 
which I think arises from wrong usage of setting parameters. In the current 
case I create packets for 2 megabytes of data (1500 bytes each) and send these 
packets. On the receiver side receiver stops receiving and quits with 
IO_STATUS_RESET after receiving approximately 300K. This problem seems to be a 
buffer problem apparently.

I don’t know if I’m missing a point in setting the parameters that arrange 
buffer space or any other point. It will be very appreciated if you provide a 
sample collection of parameters that I need to set in receiver side and in 
sender side in order to overcome this problem.  The parameters that I’m 
currently setting are following:

<pgm_multicast_receiver>

      <multicast_address>eth0;239.192.0.1</multicast_address>

      <port>7500</port>

      <udp_encap_port>false</udp_encap_port>

      <max_tpdu>1500</max_tpdu>

      <sqns>100000</sqns>

      <multicast_loop>1</multicast_loop>

      <multicast_hops>16</multicast_hops>

      <no_router_assist>0</no_router_assist>

      <recv_only>1</recv_only>

      <passive>1</passive>

      <peer_expiry_secs>300</peer_expiry_secs>

      <spmr_expiry_msecs>250</spmr_expiry_msecs>

      <nak_bo_ivl_msecs>50</nak_bo_ivl_msecs>

      <nak_rpt_ivl_msecs>2000</nak_rpt_ivl_msecs>

      <nak_rdata_ivl_msecs>2000</nak_rdata_ivl_msecs>

      <nak_data_retries>50</nak_data_retries>

      <nak_ncf_retries>50</nak_ncf_retries>

    </pgm_multicast_receiver>



    <pgm_multicast_sender>

      <multicast_address>eth0;239.192.0.1</multicast_address>

      <port>7500</port>

      <max_tpdu>1500</max_tpdu>

      <sqns>100</sqns>

      <odata_max_rte>500000</odata_max_rte>

      <txw_max_rte>400000</txw_max_rte>

      <enablefec>0</enablefec>

      <fecinfo_block_size>255</fecinfo_block_size>

      <fecinfo_proactive_packets>0</fecinfo_proactive_packets>

      <fecinfo_group_size>8</fecinfo_group_size>

      <fecinfo_ondemand_parity_enabled>1</fecinfo_ondemand_parity_enabled>

      <fecinfo_var_pktlen_enabled>1</fecinfo_var_pktlen_enabled>

      <multicast_loop>1</multicast_loop>

      <multicast_hops>16</multicast_hops>

    </pgm_multicast_sender>

I've been playing with porting this to FreeBSD 8.0 amd64 kernel.  So far
have managed to get libraries and pgmsend & pgmrecv to compile & start.

One thing I noticed was that there is a line in packet.c (~ line 200)
     gsize packet_length = g_ntohs(ip->ip_len); /*   total packet length */

From what I can tell the ip->ip_len is set from the recvmsg call in recv.c
line 197, and is already in host order.  This call then inverts the length.
Should this line actually be:

        gsize packet_length = ip->ip_len;       /* MJ: this is set by the
recv call, which returns in host order - not sure why it was different! see
recv.c:197*/

(This works on my build, but I'm not anywhere near an expert!)

See the patch.

I've faced a problem using Openpgm library, and I would be grateful if anyone 
could help me on this problem.

I want to use Openpgm on Ubuntu 12.04. according to this link: 
"https://code.google.com/p/openpgm/wiki/OpenPgm5CReferenceBuildLibrary" Openpgm 
was tested on Ubuntu 8.04 to 10.10.

I downloaded latest version of Openpgm(5.2.122) and compiled it with "scons" 
without error. According to the link I should see a compiled example named 
"pgmrecv" and "pgmsend" in path "*./ref/debug/examples/" but there isn't such 
example, Instead there was "purinrecv" and "purinsend". I run receiver first 
like this : "./purinrecv -lp 3065" then sender like this : "./purinsend -lp 
3065 please work" , there was no error message in both , but the receiver 
didn't receive anything. Any help would be appreciated!

I have a program with 2 threads. Each thread creates a PGM socket that joins a 
multicast group (e.g., thread 1 joins 239.191.99.98 and thread 2 joins 
239.191.99.99). Then each thread reads from its socket in a loop.

In my test each socket receives packets from both multicasts. That is, each 
packet is delivered twice: once to socket1 and once to socket2. 
Bug?

What version of the product are you using? On what operating system?

openpgm-5.1.118
Linux nyllmdlab05 2.6.18-164.11.1.el5 #1 SMP Wed Jan 6 13:26:04 EST 2010 x86_64 
x86_64 x86_64 GNU/Linux

My apologies for a petty report.

The libpgm-5.1.118 tar ball contains 'autom4te.cache' located in 
<install>/openpgm/pgm.

What steps will reproduce the problem?
1.to start 10 process on machine A to subscribe message published from machine B
2.machine B publish message quickly, for example (size: 2000bytes, count: 
10000), with high message rate delivery(700Mb/s)
3.unrecoverable data loss occurs every time run the test

What is the expected output? What do you see instead?
I expect that data loss will be repaired by retransmission by sender finally, 
and behaviour seen from trace log is weried, retry count up to 50(hardcoding by 
0mq) and retransmission was canncelled.

What version of the product are you using? On what operating system?
openPGM packaged in zeromq-2.1.11, linux 2.6.18-194.8.1.el5

Please provide any additional information below.
Refers to sender's log(log level: DEBUG), pgm_on_deferred_nak() was only be 
called one time when new message(NAK) arrived in pgm_recvmsgv(), why not flush 
all RDATA like wait_for_event() in blocking mode? If there is a lot of NAKs, 
sender will have little chance to do repair work. 

What steps will reproduce the problem?
1. Build the library with automake doing the ./configure; make; and sudo make 
install
2. have a function that uses pgm_send
3. try to build that and it fails

What is the expected output? What do you see instead?
I see the linker complain: undefined reference to `pgm_send'

What version of the product are you using? On what operating system?
5.1.115 linux amd64

Please provide any additional information below.

I think the symbol is hidden:
objdump -t /usr/local/lib/libpgm.a | grep pgm_send$
0000000000002e00 g     F .text  00000000000001b3 .hidden pgm_send

In the source code, there PGM_GNUC_INTERNAL decorating the pgm_send function. 
Perhaps it should not be here?

Thanks.

I am trying to build openpgm-5.2.122~dfsg in Fedora 19 with mingw32 (gcc 
4.8.1-1). But when I call mingw32-make I get an error:

recvc.: 61:37: error: dereferencing pointer to incomplete type
 # define PGM_CMSG_NXTHDR(msg, cmsg) WSA_CMSG_NXTHDR(msg, cmsg)

and some other similar errors... The windows headers patch is already applied 
to fedora's windows headers and WSA_CMSG_NXTHDR is defined as in patch.

I use PGM over UDP (no rate control). I have the following lines in my program:

//---------------------------------
m_pgmPktOffset = pgm_pkt_offset(false, 0);
m_skb = pgm_alloc_skb(1400);
pgm_skb_reserve(m_skb, m_pgmPktOffset);

pgm_skb_put(m_skb, sizeof(SeqPacketHeader));
memcpy(m_skb.tail, packet, sizeof(SeqPacketHeader));

size_t bytesWritten;
int status = pgm_send_skbv(m_sock, &m_skb, 1, true, &bytesWritten);
//---------------------------------

All UDP datagrams transmitted by this process are empty. Anything that I miss 
here?
Btw, pgm_pkt_offset() is not exposed in public header files.

What version of the product are you using? On what operating system?

openpgm-5.1.118
Linux 2.6.18-238.12.1.el5

What steps will reproduce the problem?
1. Running a kernel under qemu where TSC fails to calibrate against PIT 
(https://bugs.launchpad.net/ubuntu/+source/linux-goldfish/+bug/1318070)
2. Call pgm_init (pgm_time_init)

What is the expected output? What do you see instead?

When /proc/cpuinfo contains a valid cpu MHz, it works fine. I know this is a 
kernel issue, but opening this bug here as well as the code shouldn't crash in 
case MHz is 0.

What version of the product are you using? On what operating system?

libpgm-5.1.118 - Ubuntu 14.10

Please provide any additional information below.

From the code:
pgm_time_init (
...
        FILE    *fp = fopen ("/proc/cpuinfo", "r");
        if (fp)
        {
            char buffer[1024];
            while (!feof(fp) && fgets (buffer, sizeof(buffer), fp))
            {
                if (strstr (buffer, "cpu MHz")) {
                    const char *p = strchr (buffer, ':');
                    if (p) tsc_mhz = atoi (p + 1) * 1000;
                    break;
                }
            }
            fclose (fp);
        }
...
#ifndef _WIN32
/* calibrate */
        if (0 >= tsc_mhz) {
            pgm_error_t* sub_error = NULL;
            if (!pgm_tsc_init (&sub_error)) {
                pgm_propagate_error (error, sub_error);
                goto err_cleanup;
            }
        }
#endif
        pgm_info (_("TSC frequency set to %u MHz"), (unsigned)(tsc_mhz / 1000));
        set_tsc_mul (tsc_mhz);
    }
...
}

It calls pgm_tsc_init when tsc_mhz is 0, but that function will not run the 
benchmark because it'll return before that gets executed (by checking the tsc 
and constant_tsc flags).

pgm_tsc_init (
...
     if (!flags || !strstr (flags, " tsc")) {
        pgm_warn (_("Linux kernel reports no Time Stamp Counter (TSC)."));
/* force both to stable clocks even though one might be OK */
        pgm_time_update_now = pgm_gettimeofday_update;
        ret = TRUE;
    } else if (!strstr (flags, " constant_tsc")) {
        pgm_warn (_("Linux kernel reports non-constant Time Stamp Counter (TSC)."));
/* force both to stable clocks even though one might be OK */
        pgm_time_update_now = pgm_gettimeofday_update;
        ret = TRUE;
    }
..
}

Using revision 1458 from trunk, libpgm fails to compile. The build log states:

sockaddr.c: In function 'pgm_sockaddr_pktinfo':
sockaddr.c:485: error: 'IPV6_PKTINFO' undeclared (first use in this function)
sockaddr.c:485: error: (Each undeclared identifier is reported only once
sockaddr.c:485: error: for each function it appears in.)
make: *** [libpgm_noinst_la-sockaddr.lo] Error 1

A solution from MacPorts is to add the following to includes/config.h:

#define __APPLE_USE_RFC_2292

epgm protocol can't work on osx 10.8

publish success
'epgm://192.168.1.200;239.192.1.1:5555';

subscribe  can't receive message from pub.

What steps will reproduce the problem?
1.Sender sends chunks of data with size i.e. 2 megabytes. 
2.Receiver exits with IO_STATUS_RESET upon unrecoverable data loss. 
3.In this case(IO_STATUS_RESET) I send nak for the rest of the lost packets. 
(Still open for me how to send NAK. And also open how to send it unicast to the 
source. Any example would be very appreciated)
4.Also added nak processing thread to the sender like it's defined in daytime.c 
example.

What is the expected output? What do you see instead?

Send a nak in receiver based on a compromised specification (that Microsoft 
conforms) so that i.e. a sender based on Microsoft PGM implementation can 
interpret the message I sent from receiver as a Nak packet and retransmits it.

What version of the product are you using? On what operating system?

OpenPGM 5.1.118, ubuntu-11.04

Please provide any additional information below.

I use the following receive method in receiver

const int status = pgm_recvmsgv (m_ReceiverSock,
                                             msgv,
                                             iov_len, 
                                             MSG_ERRQUEUE,
                                             &bytes_read,
                                             &pgm_err);

What steps will reproduce the problem?
1.Modify the data transmission interval daytime.c
      #ifndef _WIN32
         usleep(10*1000);
      #else 
         usleep(10*1000);
      #endif

2.Use scons command compiler generates daytime and purinrecv(ubuntu14.04)
3../purinrecv -lp 7500 -n "eth0;239.192.0.1" and ./daytime -lp 7500 -n 
"eth0;239.192.0.1" 


What is the expected output? What do you see instead?
The receiving end of severe data loss. My hope is that all of the correct data 
packets can be transmitted to the receiving end


What version of the product are you using? On what operating system?


Please provide any additional information below.

We found it with ZMQ using PGM sockets on illumos.

OpenPGM uses its own structure pgm_ifaddrs_t which follows system ifaddrs. On 
linux. 

On illumos ifaddrs.ifa_flags is *uint64_t* [1], on linux - *unsigned int*

Thus, getifaddrs ((struct ifaddrs**)ifap) can damage memory, and it does it :-) 
(file openpgm/pgm/getifaddrs.c)


[1] http://src.illumos.org/source/xref/illumos-gate/usr/src/head/ifaddrs.h#38

Receiver implementation is like below:

while(true)
{
...
int status = pgm_recvmsgv (m_Sock, msgv, iov_len, MSG_ERRQUEUE, &bytes_read, 
&pgm_err);

switch (status)
{
...
case PGM_IO_STATUS_RESET:
  {
...
//Socket is both sending and receiving data. It's send //options are also set.
int nakStatus = pgm_send(m_Sock, nakPacket.GetBuffer(), 
nakPacket.GetBufferSize(), NULL);
...
  }
...
}
...
}

My question is: What should be the content of this nakPacket(The nak packet 
struct)?. It will be very appreciated if struct or another type is suggested 
and a sample for filling the contents of this struct is provided.

Note: In the PGM specification, it is stated that

   NAKs are transmitted by receivers to request repairs for missing data packets.

   NAKs are unicast (PGM-hop-by-PGM-hop) to the source and contain:

   NAK_TSI        OD_TSI of the ODATA packet for which a repair is
                  requested

   NAK_SQN        OD_SQN of the ODATA packet for which a repair is
                  requested

   NAK_SRC        the unicast NLA of the original source of the missing
                  ODATA.

   NAK_GRP        the multicast group NLA

So I think I must conform to that specification. I didn't find any example for 
that.