Thank you for replying, I will send you my code and the wireshark captures....But I will take little time for doing that...
To give some more information about my application....please see my comments below inlined.... On Nov 14, 2007 7:52 PM, Horvath, Elmer <[EMAIL PROTECTED]> wrote: > Hi Jhankaar, > > A few questions: > 1) Are you sending SOCK_RDM or SOCK_DGRAM? The SOCK_DGRAM may get > dropped at any point for any reason (congestion, queue limits, out of > buffers) I am sending on SOCK_RMD using sendmsg(). I checked with sendto it is working fine. > > 2) Are you blasting things as fast as possible? If you put in a slight > delay on the send does this help? There is a sleep of 1 second after every send. > > 3) If you only send multicast (and not the send to the non-existent > address) does this fix things? Yes, it works fine. What I am seeing is.... When I do a unicast send to an invalid address then this address will get set in the destnode field(ie 8th word) of the tipc header, which is correct behaviour. Now I do a send to the multicast address. But the destnode field doesnt change to the new value because of that it doesnt reach the receiver. > > It is strange that you are seeing your multi-cast not set the destnode > field, though once you are fragmenting the packet, I believe you are > seeing the header of the fragment and not the embedded multicast header. When I saw the wireshark captured packet in case of fragmentaion, the 18th word(it is in options field of the header) was also same as destnode. I am saying these specific field because when I send only multicast packets, which get fragmented, I see these fields are zeros. > > It may be advisable to send different data to the unicast address and > the multicast address to distinguish when you are capturing with > wireshark. I guess this will be self-evident when you post your code > and wireshark data. Yes I am sending different data to distinguish which packets I am receiving and which I am not.... If my first packet is unicast then I dont receive any packets and it is multicast packet then I am receiving the first packet and then no packets I get. This all is happening when I reach 1457 bytes of packet size. For 1456 I receive all multicast packets.... > > Elmer > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > jhankaar > Sent: Wednesday, November 14, 2007 4:26 PM > To: [email protected] > Subject: [tipc-discussion] Seeing an issue with unicast and multicast > onusing the same socket. > > Hi All, > > My Setup : > I am using tipc 1.5.12. > I am having 2 Redhat EL-4 machines. And on one machine I am running a > sender and on the other one I am running a receiver. > The receiver side is just receiving the packets and dropping it. > The sender code is bit different. It is sending packets alternatively to > 2 different addresses in a loop. One address is unicast address(TIPC > name address) and the other one is a multicast address(TIPC nameseq > address). The packet being sent to unicast address is a non-existant ( > or you can specify an address other than the above mentioned receiver's > address). The above mentioned receiver falls in the multicast address > group. > > The problem : > Now, when I run my applications I see that the packets are being sent > and received properly for 1456 or less bytes of data. But once I start > sending packets of size bigger than 1456 the problem starts(when > fragmentation for ethernet kicks in). I am not seeing the packets > reaching the receiver...I saw through the Wireshark that the packets are > reaching the receiver's machine but the TIPC is dropping the packets. > > > I also saw that the tipc_multicast() is not changing the destination > address(8th word of TIPC header), set for previous send. And I tried > putting zeros there explicitly and the packets are reaching the > receiver. > > Please correct me if I have assumed/doing something wrong. > And also give me some hints on how should I go further. > > Thank You, > Jhankaar > > ------------------------------------------------------------------------ > - > 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
