Martin wrote: > > 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?
Section 2.1 of the TIPC Programmer's Guide (http://tipc.sourceforge.net/doc/Programmers_Guide.txt) lists the flags supported by each socket call, although perhaps not in the most convenient way. (Try searching for names of the form MSG_xxx.) These flags are a subset of the standard socket API values, so you can also consult a standard socket API reference (I use W. Richard Stevens' classic "Unix Network Programming: Volume I") for a list of all possible flags, and then refer to the TIPC Programmer's Guide to see which ones are currently supported by TIPC. > 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? It's possible that you are trying to send traffic faster than TIPC can accept and process it. What type of socket are you using to send the data? If you are using SOCK_DGRAM, you should change this to SOCK_RDM to ensure that TIPC does not silently discard messages once the transmit queue for the multicast link gets too big. It would also be helpful to check the statistics for the multicast link (i.e. tipc-config -ls); if the bottom line shows non-zero values for "Congestion bearer: ... link: ..." this indicates that you're encountering traffic congestion issues. Note: TIPC does have mechanisms in place for dealing with excessive amounts of traffic, but they may require further testing and development to ensure they can meet that quality of service (QOS) requirements of certain users. The behavior of the multicast link under stress conditions, in particular, is one of the less explored areas of TIPC. Regards, Al ------------------------------------------------------------------------- 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
