Moin moin, all, Stephens, Allan wrote: > My first suggestion would be to upgrade to the latest version of TIPC (i.e. > TIPC 1.7.4).
Not my favourite option but if its rains on the weekend... > I also note that your application could be simplified in certain places. > Rather than calling isPacketAvailable() and then calling recv(socket, buffer, > length, 0), you can just call recv(socket, buffer, length, MSG_DONTWAIT); > this will get the message you want if it is available, or return right away > (with errno = EWOULDBLOCK) if no message is available. (In the case you want > to use MSG_PEEK, you can specify both flags by or'ing them together.) Thanks for that :-) By the way, is there a place where all the flags used in TIPC are listed? > Please continue to post your findings. It's certainly possible that you've > uncovered a problem ... I think I get a little closer to the problem. I get my system in a 'stable' progress (or at least for the last hour no failure). I have reduced the traffic load to 20%, so it looks a little bit like problems with the queues. A few numbers: What I tried to send was ~2000 packets/sec (I count one packet if it is received by one and two packets if it is received by two) distributed to ~20 receivers. Each packet has around 30 byte. I have reduced this to ~400 packets/sec and 10 receivers. Have I only overload the TIPC or have I still deeper problems? How can I notice, that I tried to put to much on the TIPC? cu Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
