Sending nak in receiver and how to handle nak interoperability for windows

[GoogleCodeExporter]

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);

Original issue reported on code.google.com by [email protected] on 5 Oct 2011 at 7:58

[GoogleCodeExporter]

IO_STATUS_RESET means that the NAK-RDATA cycle has repeatedly failed, i.e. the 
Microsoft PGM stack is not sending sufficient repairs.

I recommend using the debug build of OpenPGM, enabling all traces, monitoring 
with WireShark and follow where and why the NAKs are either not being sent or 
RDATA not being send or received.

Original comment by [email protected] on 5 Oct 2011 at 3:20

[GoogleCodeExporter]

One concern is the version of Microsoft PGM in use, 2MB messages are no longer 
supported since DoS limitation to protocol reported in MS08-036, KB950762.

Original comment by [email protected] on 5 Oct 2011 at 3:24