pgm_recv blocks when it shouldn't

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by harrison...@gmail.com on 6 Apr 2011 at 6:42

[GoogleCodeExporter]

This is how it used to be, in r484 for example flags is set to MSG_DONTWAIT.  
The problem being that non-blocking on the receive is not portable to Windows 
platforms and so it is preferred to set the entire socket non-blocking.

Also, blocking sockets break the concept of state management by time.  There is 
no ability to drop out of the receive to send a NAK, this would be dependent 
upon extra threading as per OpenPGM version 1.

So the real issue is that socket non-blocking is set in the socket option 
PGM_NOBLOCK and not in pgm_socket after creating the underlying sockets.

Original comment by fnjo...@gmail.com on 7 Apr 2011 at 1:34

• Changed state: Accepted

[GoogleCodeExporter]

The major design question around blocking sockets is how should transmission be 
handled.  Reception requires non-blocking sockets always in order for time 
management.  Transmission is a mixed bag, for sending NAKs the transmission is 
handled in the receiver and so non-blocking is preferred, but using 
non-blocking sends in pgm_send et al would be non ideal with a select() loop 
waiting for non-blocking send.

Original comment by fnjo...@gmail.com on 7 Apr 2011 at 2:13

[GoogleCodeExporter]

Please try trunk which defaults to non-blocking recv sockets internally but 
pgm_recv et al will show blocking semantics.  Passing the flag MSG_DONTWAIT 
will convert to non-blocking semantics on Unix platforms.

http://code.google.com/p/openpgm/source/checkout

Original comment by fnjo...@gmail.com on 7 Apr 2011 at 2:21

• Changed state: Started

[GoogleCodeExporter]

Closing, presumed fixed with trunk modifications.

Original comment by fnjo...@gmail.com on 5 Oct 2011 at 3:21

• Changed state: Fixed