Hi Martin: My first suggestion would be to upgrade to the latest version of TIPC (i.e. TIPC 1.7.4). The TIPC 1.7 stream contains a number of changes that improved TIPC's behavior on multi-core systems. You can find a link to the TIPC 1.7.4 software at http://tipc.sourceforge.net/download.html.
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.) Please continue to post your findings. It's certainly possible that you've uncovered a problem ... Regards, Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Rosekeit Sent: Thursday, August 30, 2007 2:33 PM To: [email protected] Subject: Re: [tipc-discussion] receiving problem Moin, moin, sorry, my system: TIPC 1.6.2 Intel Core Duo processor T2500 (2GHz) Linux, Ubuntu (Feisty Fawn) 7.04. with kernel version 2.6.20-16-386 Stephens, Allan wrote: > Hi Martin: > > Can you please provide the following info about your setup? This will assist > us in determining if your problem is a known issue, or one that has already > been fixed. > > * your version of TIPC (eg. TIPC 1.5.9) > * your hardware platform (eg. Pentium 3) > * your operating system (eg. Linux running Fedora Core 3 with kernel > version 2.6.11) > > Thanks, > Al > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Martin Rosekeit > Sent: Thursday, August 30, 2007 1:24 PM > To: [email protected] > Subject: [tipc-discussion] receiving problem > > Moin, moin, > > I have a reliability problem on receiving messages and I am running out of > how to debug that. > The communication use the multicast mode (from the multicast-demo). The > receivers running in different threads with set filters to separate the > messages. In general this works really good. > > But sometimes (each 5th to 10th program start) after a few messages were > successfully received, no new messages from one type will reach the receiver. > If the receiver has set filters for more then on type, it is still possible > to receive the other messages. > When I start this receiver a second time (parallel to the already running > process), then the new receiver gets the messages, while the old one still > does not get the message. > I checked on the set filters with 'tipc-config --nt' and everything is in > place. > An 'tipc-config -log' results in a 'log is empty'-prompt. > > At the moment I do not know what to make next to get right of the problem. > > Perhaps something is wrong in socket-handling, so please have a look: > > Thank you > Martin Rosekeit > > // transmitter > --------------------------------------------------------- > void > TipcTransmitterSocket::transmitPayload( unsigned int typeId, > unsigned int instanceId, > char* payloadPointer, > size_t length) { > int sendToResult = 0; > > sockaddr_tipc tipcToAddresse; > > // Initialize the toAddress struct of TIPC. For further documentation > have a look > // into the Multicast-Demo which is included into the TIPC-Demo package. > tipcToAddresse.family = AF_TIPC; > tipcToAddresse.addrtype = TIPC_ADDR_MCAST; > tipcToAddresse.addr.nameseq.type = typeId; > tipcToAddresse.addr.name.domain = 0; > tipcToAddresse.addr.nameseq.lower = instanceId; > tipcToAddresse.addr.nameseq.upper = instanceId; > > sendToResult = sendto( this->socketDescriptor_, > (void*)payloadPointer, > length, > 0, > (struct sockaddr*)&tipcToAddresse, > (size_t)sizeof(tipcToAddresse)); > > // Check if the sending failed > if (sendToResult < 0) { > std::cerr << "\nERROR in TipcTransmitterSocket::transmitPayload() on > transmit."; > } > } > > // receiver -------------------------------------------------------- > // The methode receive() is called two times and then pop(). > > void > TipcReceiverSocket::registerOnPacket( unsigned int typeId, > unsigned int lowerInstance, > unsigned int upperInstance) { > > int result = 0; > struct sockaddr_tipc fromAddress; > > fromAddress.family = AF_TIPC; > fromAddress.addrtype = TIPC_ADDR_NAMESEQ; > fromAddress.addr.nameseq.type = typeId; > fromAddress.addr.nameseq.lower = lowerInstance; > fromAddress.addr.nameseq.upper = upperInstance; > fromAddress.scope = TIPC_CLUSTER_SCOPE; // Scope of > puplisching is cluster (node < cluster < zone) > > // Binding means registering to a specific packet > result = bind ( this->socketDescriptor_, > (struct sockaddr*)&fromAddress, > sizeof(sockaddr_tipc) ); > > if (0 != result) { > printf("Port {%u,%u,%u} could not be created\n", > fromAddress.addr.nameseq.type, > fromAddress.addr.nameseq.lower, > fromAddress.addr.nameseq.upper); > } > } > > // from TIPC-Demo, benchmark/client_tipc.c ( wait_for_msg() ) bool > TipcReceiverSocket::isPacketAvailable() > { > int result = 0; > > struct pollfd pfd; > > pfd.fd = this->socketDescriptor_; > pfd.events = ~POLLOUT; > > result = poll( &pfd, > 1, > 0 // do not wait > ); > > return (result > 0); > } > > bool > TipcReceiverSocket::receive(char* ptr, size_t payloadLength) { > if ( this->isPacketAvailable() ) { > > int result = 0; > > result = recv( this->socketDescriptor_, > ptr, > payloadLength, > MSG_PEEK); // Do not delete data from TIPC > > if( result > 0 ) { > return true; > } > else { > std::cerr << "\nERROR: TipcReceiverSocket::receivePayload()"; > } > } > return false; > } > > // This method removes the current packet from the TIPC message queue. > bool > TipcReceiverSocket::pop() > { > int result = 0; > > if ( this->isPacketAvailable() ) { > char c; // TODO: Better way? > result = recv( this->socketDescriptor_, > &c, // We need no space for data > 1, // We read no data > 0); // Delete data from TIPC > > return true; > } > return false; > } > > -- > <<Experience is what you get, when you don't get what you want.>> > > Martin Rosekeit > Karlstraße 9 > 27607 Langen > Germany > > Phone: +49 (0)4743 5857 > Mobil: +49 (0)160 92505707 > ICQ: 153 913 172 (Thundernail) > Jabber: [EMAIL PROTECTED] > Skype: thundernail > > www.thundernail.de > www.ring1.de > > ---------------------------------------------------------------------- > --- 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 -- <<Experience is what you get, when you don't get what you want.>> Martin Rosekeit Karlstraße 9 27607 Langen Germany Phone: +49 (0)4743 5857 Mobil: +49 (0)160 92505707 ICQ: 153 913 172 (Thundernail) Jabber: [EMAIL PROTECTED] Skype: thundernail www.thundernail.de www.ring1.de ------------------------------------------------------------------------- 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 ------------------------------------------------------------------------- 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
