I'm afraid I can't help you with you specific pgm problem, but if you don't mind me playing devil's advocate for a second, it seems like you're doing a lot of engineering work to distribute a file to 20 servers. Have you considered using an existing multicast tool like uftp or udpcast to distribute the file?
-Michel On Thu, Apr 17, 2014 at 8:26 PM, lzx.bupt <[email protected]> wrote: > Hi All, > Our company is using zeromq's *pub/sub pattern with pgm/epgm*. > Our aim is to multicast many big files(about 1GB/2GB/5GB) to 20 server > nodes in a short time. Because we want to insure the files' integrity, > we treat a big file as *a big message using* "*ZMQ_SNDMORE*" option for > messages except for the last one. > > * Problem: * > When we do the performance test, we find a strange problem. When > using a low sending rate(ZMQ_RATE<20MB/s), there are no data lose for all > receivers and for different files. But, when using higher sending rate( > ZMQ_RATE>30MB/s), some receivers begin to lose message. > * The strange problem is that these receivers do not know they > had lost a message(or a file), the function "**zmq_msg_recv" did not > return any error. *I know an unrecoverable message occured, but* these > receivers seems to still receive from the socket, they do not drop the data > part received.* *These strange receivers still want to receive the last > part message, so they do not give the **imperfect message to user-level > application. * > when the pub-server send another small size message (first file > is 5GB, later one is 50MB), these strange receivers, who did not receive > 5GB message, receive 5GB message again, not the 50MB message. * It seems > that they treat 50MB size message as the last part of 5GB message, so they > consider the former 5GB message is available and give it to user-level > application*, but the 5GB message is a dirty message with less data and > wrong data. > > What's happening with openpgm? Is there any api for getting the > message status from openpgm? We want to know we have lost a message, we do > not need a non-complete message. > Could you gus help us? > > Thank you very much! > ------------------------------ > lzx.bupt > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
